Another thing to consider, and this is true for all third party developers, is that quite possibly two versions of such software could be required: one for Big Sur compatibility on Intel-based Macs, and one for Big Sur compatibility on the new Silicon Macs.
Thanks to Rosetta the only ARM vs. Intel issue should be how much of a performance hit Rosetta will impose and it is highly likely the ARM will be fast enough that hit will be unnoticeable. There will undoubtedly be a period where apps will have universal (both Intel and ARM executables in the same package) but that will be because of performance issues and a desire to retain backward compatibility with the installed Intel user base, but I expect one of the first available third party utilities will be to remove either the ARM or Intel code from the application package to reduce the size; there are still one or two left from the PowerPC to Intel transition that should be a snap to adapt. The dual version approach was attempted by a few, very few, developers during the PowerPC to Intel conversion, but that drastically increased the development costs, and was quickly abandoned. I doubt any will make the same mistake this time around.
What is already an issue for developers of kernel extensions, is some of the APIs they used were deprecated a couple of years or more back and are totally removed from MacOS 11. Still others, who have relied on embedding their kernel extensions deep in the bowels of the OS, have found installing their extensions breaks the seal on the boot snapshot rendering it un-bootable and they are having to figure a new way to do their job without taking a major performance hit. But neither of these issues, or the clone issue, are processor related, rather a function of hardening the MacOS SYSTEM, and impact Intel and ARM systems equally. Developers who follow sound design and coding practices, and stay within Apple's guidelines, should encounter few problems.
If we knew what it was we were doing, it wouldn't be called research, would it?
