Custom Metadata Types support various relationships. They can have multiple records created against them which would allow you to manage individual mappings. They even allow you to have effectively parent/child relationships. Combining this with Entity Definition and Field Definition type fields would allow you to create the sort of configuration you've described; a parent CMT record representing the over-all mapping and records of the child CMT as the individual field mappings.
The benefit of this approach is the adoption of standard Salesforce functionality, with appropriate validation of field selections etc. Unfortunately the UX is not ideal, with the admin having to create and/or edit many separate records to define the configuration.
However, a distinct downside that we measured back on Summer '19 and earlier (it may be that Salesforce have improved this in the more recent editions) was performance; the in-Apex evaluation of the Entity and Field Definition type fields was exceedingly poor and we found that our CMT-based mapping configuration became far too expensive in CPU terms - just to load the CMTs and resolve the mapping would take 100s of milliseconds and the more individual field mappings defined the heavier the processing just to load the data. This then becomes highly problematic when the mapped records themselves have a lot of trigger, process builder or flow-based processing (which was the case on one specific customer org for us, where they had also added a lot of custom field mappings).
This then meant that it was impossible to scale to larger numbers of records being inserted or updated together through the REST API and that meant spending time on refactoring the REST API client to stay within limits, which is not a good idea.
The alternative solution we subsequently adopted was to publish our own JSON schema that describes the configuration for the mapping held as a string field in a single Custom Metadata Type record. We defined the schema avoiding any Apex reserved words so it is easy to parse the JSON into an Apex class instance structure using JSON.deserialize. The schema might describe a structure like:
{
"mapping": {
"baseProperty": "something",
"objectType": "MyCustomObject__c",
"properties": [
{
"fromProperty": "blah",
"toField": "Example__c"
}
]
}
}
Depending on your needs, you will have your own structure.
By publishing a JSON schema (we actually make sure the schema ID is a valid URL on our website to actually fetch the schema through) we allow the admin to use some schema-aware JSON editor that they can copy/paste to and from when editing the CMT-based mappings.
This has the distinct disadvantage that the Salesforce UX on the CMT is rubbish - it's just a large text box - and there's no immediate validation that the fields specified are valid.
However, this approach makes the CMT loading and parsing take just a few milliseconds since we can use the "static schema access" approach to resolving object types and field paths.
It also means we can have quite complex configuration schemas that provide lots of basic validation (such as ensuring that object types and field paths look valid, for example) and auto-completion support when used with appropriate schema-aware JSON editors (such as IntelliJ IDEA, but there are others). Note that I haven't found a free online JSON schema aware editor that can support auto-completion, but they do supply validation handling. There are various free downloads for such tools as well.