At that point, Module::A becomes immediately available to all 9 architectures, even though it has not been tested against 8 of them. This is an unsatisfactory state of affairs, IMO.

Even more unsatisfactory, Module::A would be available on all 9 architectures possibly lacking many of its XS dependencies, and completely fail to work until someone ran cpanm under each other architecture to get the dependencies installed.

How do module authors generally deal with this issue ?

I don't think any module authors ever deal with it. This general usage pattern can't be fixed by a single module author; it would require all pure-perl modules with XS dependencies to always be installed in the architecture-specific location. I've never used this usage pattern either; every perl of a different arch that I've used has always had a complete standalone lib directory. (using perlbrew or plenv) I would guess the only time the multi-arch directories are actually intended to be used are when you have perl libs shared on NFS or a binary package repo or something like that. In that case, an administrator or distro maintainer would ensure the state of each arch before releasing the changes to the user base.

Since you have to install your module 9 times anyway, you might consider automating it with something like Carton. Carton records the version of every module dependency installed, and would re-install all the dependent modules as you re-run it under each arch.