I believe they are considered two different concepts. The multiple inheritances is a “diamond shape”, but it seems to me you think about it as an inheritance chain.
Let’s say you have the preset “release”, “debug”, “env”. If you create “default” that inherits from “debug” which in turn inherits from “env” it is a chain of inheritance “default"→"debug"→"env”. However, if you put [“release”, “debug”] in the inheritance of “default”, “default” inherits from both at the same level. The rule of resolution has nothing to do with the inheritance overwrite and the order in which the inheritance priority should be decided is a new question entirely, so why not choose to put priority from left to right (from the start of the list to the end)?
I hope this answer helps you despite being a few months late!
If I understand correctly, you expect that [release, debug, coverage] would behave like if coverage was inheriting from debug, and debug from release. However, in a chain of inheritance, you do not have to choose between multiple values for a single variable. Let say coverage has CMAKE_BUILD_TYPE set to RELEASE, debug inherits from coverage and defines CMAKE_BUILD_TYPE to DEBUG. Then debug only contains one value for CMAKE_BUILD_TYPE, which is DEBUG. So if you would make “default” that inherits from debug, default would have DEBUG as value for CMAKE_BUILD_TYPE because there is no other choice.
If instead you define “default” as inheriting from [release, debug, coverage], then you are in a completely different situation, you might have 3 definitions of CMAKE_BUILD_TYPE and need to choose which one you are going to keep. Their choice was to put priority on the first one in the list, but they could have done the opposite.
I am not saying I agree or disagree with this choice, the argument is here only to try to explain that the rules do not differ between chained inheritance and multi-inheritance but rather that we have two different concepts that have their set of rules. I am trying to address your last question:
In the meantime, I am completely confused from cmake docu and discussion:
The preset will inherit all of the fields from the inherits presets by default
(except name, hidden, inherits, description, and displayName),
but can override them as desired.
Does this mean, there is no inheritance hierarchy possible with cmake presets?
If I want to merge values from different presets, I have to use an inheritance list?
I do not think so. Let’s say you have a preset “default” that inherits from “debug”. “debug” has CMAKE_BUILD_TYPE set to DEBUG, then “default” inherits the field CMAKE_BUILD_TYPE with value DEBUG. Therefore “debug” has the field CMAKE_BUILD_TYPE set to DEBUG. Thus, if you would now create a preset “custom” that inherits from “default”, “custom” would inherit CMAKE_BUILD_TYPE with value DEBUG from “default”. So, indirectly, “custom” inherits from “debug”, but “debug” is not in the inheritance field of “custom”. If it is not clear enough, consider this specification as a technicality and keep in mind that, “custom” inherits fields from “debug” unless they have been redefined in “default”, or in “custom”.