Possibly, the smartest comment I've read in the last 12 months :)
You're 100% correct. It's not really the plugin name the thing that has to be chosen, but rather plugin directory name. It is fetched by the glob function. Furthermore, as it comes from the file system, plugin order depends on the file system rules, so capitalization matters.
A similar scenario happens with plugin layers that don't call their parent method, they just destroy the chain. Sometimes there isn't much to do about it.
I think renaming the directory is just a workaround but I can't figure out a bullet-proof approach for this:
1. I thought about adding metadata in the metadata.json file so that plugins can state their execution order (e.g. run_after: [ "plugin_id1", "plugin_id2" ]) but this will require plugins to have an ID (something I suggested 5 years back and developers still don't respect:
https://www.question2answer.org/qa/31654) and also plugin developers will have to KNOW about those other plugins and add them in the metadata as dependencies. So this solution doesn't scale.
2. I also thought of adding priority to plugins in their metadata. Just a float number between 0 and 1. Then developers will know whether they want to execute as close to the beginning of the execution process (0) or at the end (1). This could fix the issue that you brought up but only if there is just one plugin with priority 1. Having 2 would mitigate the issue, of course, but still there is chance of breaking
At the end of the day, it depends so much in the plugins a user is running in their system that thinking in dependencies or priorities set by the plugins themselves is not the perfect solution. The best approach I could come up with is letting the user define the plugin execution order. For example, setting it in admin/plugins somehow (e.g. adding some arrows to move them). I think most users will have no idea what to do with that, though.