It's unlikely to be that simple. There will be many other modules that also have components under the lib/auto directory.

It would be much simpler to distribute separate applications during the transition period.

If the former, then you could write your Makefile.PL to detect the bit-width of perl and set the appropriate make flags, so that one distribution can be installed in both perls. You can't really share the resulting directory between multiple versions of Perl because the installer tools like 'cpanm' will only install the 32 *or* 64 bit versions of all your dependencies. When the user switches perl versions, they need to start from an empty module include path and re-install things as needed.

If the latter, and you're distributing binaries (which presumes you know the exact version of Strawberry for both bit-widths of perl your customers are running) then yes you could make a 32-bit build and a 64-bit build that use different directory names for the Tk .dll files, and just merge the trees together before you ship it to the customer. This would save a lot of redundant pure-perl source files from getting installed.

If you run into trouble, the simplest solution would be to just ship a complete 32-bit and complete 64-bit module tree, and write a front-end script that chooses which path to add to @INC based on which perl ran it.

Thanks for your thoughts!
I think I was not clear enough about the used directory structure. The application is a single pure Perl script (not implemented as a module) delivered as an entire tree of files including non-system modules being used.
The application is used as a "local" installation (not under "Program Files", but in it's own bin directory with needed modules supplied also locally in sub directories). It is a bundled set residing in one directory.
The Perl installation OTOH is globally (standard installation from msi installer).
The question is if I could merge 32 and 64 variants of needed modules locally together, to be 32/64-Bit agnostic.

That's pretty close to scenario #2.

So presumably in your script you say something like

use FindBin;
use lib "$FindBin::Bin/lib/";
[download]

My basic suggestion is that you can change it to

use FindBin;
use Config;
use lib ( $Config{archname} =~ /64/? "$FindBin::Bin/lib64" : "$FindBin
+::Bin/lib32" );
[download]

and just ship two complete collections of modules. Then, if you inspect those trees of files and manage to make it so that they don't have any non-identical collisions, you could merge the trees back into a single lib directory. The merge is just nice to save disk space, and not required for supporting both perl versions. If there are collisions, you can decide how much time to spend fiddling with it vs. the size cost of just shipping dual lib directories. "diff -r" can tell you whether any of the perl modules change their installed .pm files when installed under a different arch.

You could even go for a hybrid approach where you install all the non-XS modules under ./lib/, and then install the XS under ./lib32 and ./lib64, and already get most of the space savings without any effort.

Have you considered using PAR::Packer as a distribution method?