Is your feature request related to a problem? Please describe.

From R5

R5 has the new obligation extension that can (optionally) be used on Must Support elements to be more specific in what it means in that context: http://hl7.org/fhir/extensions/StructureDefinition-obligation.html
As stated on http://hl7.org/fhir/R5/obligations.html#obligations:

If an element is labelled as "must-support", the element can specify the obligations associated with its use by providing one or more obligations using the Obligation.

It also introduces the Impose Profile extension, which indicates additional profiles that a resource should be validated against: http://hl7.org/fhir/extensions/StructureDefinition-structuredefinition-imposeProfile.html

Instances can only be valid against this profile, if they also successfully validate against the profile referenced by this extension.
This is an instruction to validators to go and check the profile this extension refers to, and enforce that the instance being validated is valid against both source and target profiles. In general, the source profile won't restate the constraints in the target profile.

From the Tooling IG

Alternatively the tooling introduces an alternative way to comply with two profiles, leveraging Obligation, called the Inherit Obligations extension: https://build.fhir.org/ig/FHIR/fhir-tools-ig/StructureDefinition-inherit-obligations.html

Inherit all the obligations from an Obligation Profile

The Obligation Profile Flag extension marks profiles as an obligation profile: https://build.fhir.org/ig/FHIR/fhir-tools-ig/StructureDefinition-obligation-profile.html

Profiles marked to be ‘Obligation Profiles’ cannot introduce new structural elements or slicing, but they can add additional bindings, and additional obligations on the elements that are already defined

Why are they useful?

• The Obligation extension makes the ambiguous Must Support flag more computable.
• Impose Profile and Obligation Profiles both provide a way to allow an author to comply both with, for example, a National base IG and an international realm use case IG. Or, a company wide base IG and a national base/use case IG.

Describe the solution you'd like
Can we support these concepts in the SDK so users can experiment with the best way of conforming with multiple IGs which are not in the same hierarchy?

I imagine the Obligation and Impose Profile extension mainly influence the validator and the Obligation Profile to impact snapshot generation.
Perhaps we should split in three tickets (in order of priority: Obligation extension / Impose Profile / Obligation Profiles), but started like this given their relationships.

Describe alternatives you've considered
Currently these can be used in the IG Publisher for testing.

Additional context
Supporting the tooling IG is more widely captured in #2346