One small question for WPF

Quote:

If it was "Key" rather than "x:Key" this would require "Key" to be an "attribute" of
the "element" added as a resource, according to the syntax rules of XAML and even XML.

In WPF this would mean that every object added as a resource
would need to expose a writable DependencyProperty named "Key".

This would rule out all types that are not DependencyObjects - such as strings or URIs or
ViewModels instances - and more over all those that don't have such DP named "Key",
so merely all objects commonly used as resources!

With the implementation as "x:Key" directive the key doesn't need to be a true attribute of
the element added, you can look it as kind of an "attached" attribute to the element (just allegorically
not technically an AttachedProperty).
Note that if a type has a property marked by the DictionaryKeyPropertyAttribute then you
actually don't need the "x:Key" but may rather use the "Key" property of that type (which may have a different name) - just the way you proposed.

Note that for "x:Name" and "Name" the relation is about the same as for "x:Key" and "Key".
If you use "Name" the element needs to expose a writable DP named "Name",
which in contrast to "Key" is most often the case - because "Name" is a DP of
every FrameworkElement and FrameworkContentElement, so >90% of elements used in XAML,
so that's why Name and x:Name often appear as synonyms and mutually interchangeable
(which they are not fully) but "x:Key" and "Key" do not.