For clarification @John.
It isn't only .so files and not only one.
Of the former non-arch .so files we now have the following in proper directories:

open-vm-tools-desktop
./usr/lib/x86_64-linux-gnu/open-vm-tools/plugins/vmusr/libdesktopEvents.so
./usr/lib/x86_64-linux-gnu/open-vm-tools/plugins/vmusr/libdndcp.so
./usr/lib/x86_64-linux-gnu/open-vm-tools/plugins/vmusr/libresolutionSet.so

open-vm-tools-dev:
./usr/lib/x86_64-linux-gnu/libDeployPkg.a
./usr/lib/x86_64-linux-gnu/libDeployPkg.so -> libDeployPkg.so.0.0.0
./usr/lib/x86_64-linux-gnu/libguestStoreClient.a
./usr/lib/x86_64-linux-gnu/libguestStoreClient.so -> libguestStoreClient.so.0.0.0
./usr/lib/x86_64-linux-gnu/libguestlib.a
./usr/lib/x86_64-linux-gnu/libguestlib.so -> libguestlib.so.0.0.0
./usr/lib/x86_64-linux-gnu/libhgfs.a
./usr/lib/x86_64-linux-gnu/libhgfs.so -> libhgfs.so.0.0.0
./usr/lib/x86_64-linux-gnu/libvgauth.a
./usr/lib/x86_64-linux-gnu/libvgauth.so -> libvgauth.so.0.0.0
./usr/lib/x86_64-linux-gnu/libvmtools.a
./usr/lib/x86_64-linux-gnu/libvmtools.so -> libvmtools.so.0.0.0
./usr/lib/x86_64-linux-gnu/pkgconfig/
./usr/lib/x86_64-linux-gnu/pkgconfig/libDeployPkg.pc
./usr/lib/x86_64-linux-gnu/pkgconfig/vmguestlib.pc

open-vm-tools-sdmp:
./usr/lib/x86_64-linux-gnu/open-vm-tools/plugins/vmsvc/libgdp.so
./usr/lib/x86_64-linux-gnu/open-vm-tools/plugins/vmsvc/libguestStore.so
./usr/lib/x86_64-linux-gnu/open-vm-tools/plugins/vmsvc/libserviceDiscovery.so
./usr/lib/x86_64-linux-gnu/open-vm-tools/serviceDiscovery/
./usr/lib/x86_64-linux-gnu/open-vm-tools/serviceDiscovery/scripts/
./usr/lib/x86_64-linux-gnu/open-vm-tools/serviceDiscovery/scripts/get-connection-info.sh
./usr/lib/x86_64-linux-gnu/open-vm-tools/serviceDiscovery/scripts/get-listening-process-info.sh
./usr/lib/x86_64-linux-gnu/open-vm-tools/serviceDiscovery/scripts/get-listening-process-perf-metrics.sh
./usr/lib/x86_64-linux-gnu/open-vm-tools/serviceDiscovery/scripts/get-versions.sh

open-vm-tools:
./usr/lib/x86_64-linux-gnu/libDeployPkg.so.0 -> libDeployPkg.so.0.0.0
./usr/lib/x86_64-linux-gnu/libDeployPkg.so.0.0.0
./usr/lib/x86_64-linux-gnu/libguestStoreClient.so.0 -> libguestStoreClient.so.0.0.0
./usr/lib/x86_64-linux-gnu/libguestStoreClient.so.0.0.0
./usr/lib/x86_64-linux-gnu/libguestlib.so.0 -> libguestlib.so.0.0.0
./usr/lib/x86_64-linux-gnu/libguestlib.so.0.0.0
./usr/lib/x86_64-linux-gnu/libhgfs.so.0 -> libhgfs.so.0.0.0
./usr/lib/x86_64-linux-gnu/libhgfs.so.0.0.0
./usr/lib/x86_64-linux-gnu/libvgauth.so.0 -> libvgauth.so.0.0.0
./usr/lib/x86_64-linux-gnu/libvgauth.so.0.0.0
./usr/lib/x86_64-linux-gnu/libvmtools.so.0 -> libvmtools.so.0.0.0
./usr/lib/x86_64-linux-gnu/libvmtools.so.0.0.0
./usr/lib/x86_64-linux-gnu/open-vm-tools/plugins/common/libhgfsServer.so
./usr/lib/x86_64-linux-gnu/open-vm-tools/plugins/common/libvix.so
./usr/lib/x86_64-linux-gnu/open-vm-tools/plugins/vmsvc/
./usr/lib/x86_64-linux-gnu/open-vm-tools/plugins/vmsvc/libappInfo.so
./usr/lib/x86_64-linux-gnu/open-vm-tools/plugins/vmsvc/libdeployPkgPlugin.so
./usr/lib/x86_64-linux-gnu/open-vm-tools/plugins/vmsvc/libguestInfo.so
./usr/lib/x86_64-linux-gnu/open-vm-tools/plugins/vmsvc/libpowerOps.so
./usr/lib/x86_64-linux-gnu/open-vm-tools/plugins/vmsvc/libresolutionKMS.so
./usr/lib/x86_64-linux-gnu/open-vm-tools/plugins/vmsvc/libtimeSync.so
./usr/lib/x86_64-linux-gnu/open-vm-tools/plugins/vmsvc/libvmbackup.so

I'd have assumed that plugins are only used internally, it seems odd to me that it uses a file from the plugin paths, but indeed that is what I see in
https://github.com/canonical/cloud-init/blob/main/tools/ds-identify#L902

My assumption so far would now be that:
1. This is a non critical artifact of myself handling them as if there "could be binaries". But we might mid term want to move the shell scripts of open-vm-tools-sdmp to a non arch path as they do not have per-arch content. @John could you confirm that this path will never include binaries?
2. as a temporary workaround for bad old deps we will add a compat link from the old /usr/lib/open-vm-tools to /usr/lib/$(DEB_HOST_MULTIARCH)/open-vm-tools