MC never complained about attack name conflicts.
Not that the engine handles conflicting stack names perfectly, but it does (or at least as of a few years ago, did) handle them far more gracefully than the LC IDE would lead newcomers to expect.
How this came about is understandable: for LC's first several years (then RunRev), the company has no control over the engine they were licensing, but they did have total control over their own IDE. So when they encountered an issue, working around it in the IDE was a good option for taking action.
But of course we've seen conversations like this one every few months for a quarter century, which led some years ago to this request:
https://quality.livecode.com/show_bug.cgi?id=1061
Then a couple years later I had some time on my hands and did a deep dive to see more precisely what works and what doesn't with the engine's resolution of stack names. It turns out there is an issue in the engine, but it's seemingly more minor than the sturm und drung users experience with the IDE's complete refusal to open stacks of the same name at all::
https://quality.livecode.com/show_bug.cgi?id=18793
In short, the engine resolves stack references by load order rather than window layer order, occasionally referring to an unexpected stack when there's more than one with the same name.
I say "seemingly more minor" because a C++ expert is in a better place to assess complexity of refining that than a scripting expert.
Nonetheless, a handler this scripter provided in that second report returns the occurrence of the topmost stack instead of the one loaded first when there are multiple stacks of the same name.
It may not always be a fair assessment, but having worked closely with so many xTalk engine teams over the decades I'm generally of the opinion that a solution that can be provided in script can be implemented in the engine executing the script.
So what remains seems a matter of priority.
Given the value of being able to compare different versions of the same stack, and the complications that arise from not being able to do so, I would apply different priorities. But I'm not them and they're not me; we each see what we see through a different prism of relative importance.