I think everyone here already quite well appreciates (and have even already expressed) your concerns - lifelong knowledgebase, interoperability with other apps, etc… - thus UUIDs in filenames was only ever seriously considered by fanantoxa and he quickly realized that it wasn’t the way to go after being made aware of the previous discussion on the issue.
Moreover, it seems to me(/us?) that your concerns are good arguments for a well-thought-out UUID mechanism. As described by OP, the current external link format is utterly useless for interoperable-use outside of Obsidian since renaming files - as will inevitably happen for most people - immediately breaks the links. Any feasible workaround for this - e.g. a system-wide search/replace - is laughable and bound to fail due to user-error. It is for these reasons that UUIDs need to be not just a community plugin (which is perhaps a necessary starting point for the sake of expediency/proof-of-concept), but built-into the core functionality of Obsidian.
Of course, proprietary UUIDs in some hidden database, however they may be implemented - there are many apps mentioned above, like Onenote, Bear, Zotero etc… - cannot realistically be carried forward if we decide to migrate to another app for whatever reason. YAML seems to solve this problem nicely, as it does for metadata generally - the UUID information is just sitting there in plaintext, ready to be parsed and integrated into the other app (something that has to be done anyway with filenames and other linking formats).
Once the UIDs come into play
[[Note A]]could link to any of many (for the sake of argument let’s say dozens ) of notes that happen to have the same name but unique IDs
This isn’t an inevitable outcome for UUIDs, especially if done through a plugin since Obsidian (actually, the filesystem) already blocks using same filepaths. If someday UUIDs were to be baked into the core of Obsidian, as should be done, it would have to still adhere to this unique filepath restriction. YAML makes this even easier.
I’m not smart enough to actually design the architecture for implementing this, but hopefully @fanantoxa can get us to a good starting point and if we can get enough support for this crucial issue, perhaps the Wizards of Obsidian will be able to polish it off.
Does this address your concerns? If not, what is missing still?