I suggest to raise an issue on the modules GitHub page:
It is indeed not good practice to break that API.
At the same time there is good reason to have such an action as it improves maintainability (Find usages, renaming microflows...)
Regarding API breakage: our policy is that breaking APIs is only allowed for a Major version change:
* version 7.0.0 may introduce changes compared to 6.10.0,
* but 7.1.0 should be API compatible to 7.0.0
Of course you can break your APIs. However, in such a case you should release a new version. That is exactly what Mendix is doing: they have released a new version. You are not forced to use the new version (the old version of CommunityCommons can still be downloaded), just like a consumer of your API shouldn't be forced to use the new version.
If AppServices work in another way (I wouldn't know, I don't use them as I believe they don't add value), it might be because Mendix chose easy of consumption over ease of change, which one could argue is a sensible choice for novice developers.
Out of curiosity; what does your application do that introduces the need to dynamically construct the name of the microflow to be called?