In your example, a <section name="A B"> would generate the same id as the first subsection, so this is not fool proof.
My personal opinion is that the plugin should not auto-generate id's at all (except where they are only used internally, like for the table of contents, in which case the user does not need to know anything about it). The only raison d'etre for the id generation for sub/sections is to make it referencable for the user. If the user wants to reference a sub/section, he should provide an id himself.
Note that in the old version of the plugin, before my fix for
MPPDF-24, ids for sub/sections were generated using xslt's generate-id() function, which gave a unique id in all cases. However, they were completely useless because they were re-generated dynamically at each build time and the user couldn't know how to reference them. I conclude that if you want to ensure unique ids, you would have to auto-generate them according to some algorithm, but in that case they are useless because they can't be referenced. If you want id's that the user can reference easily, there is no way to ensure they are unique.
I'd rather propose to remove the id generation from name tags altogether and keep the id tag as an option (that's how it should be in the xdoc plugin as well). Thus, we maintain backwards compatibility within the pdf plugin and avoid any build failures. The worst thing that can happen is that a link to a section does not work in the generated pdf if the user forgets to specify an id tag.