armhf and armel are on their way out anyhow. Do Debian repos support all Debian archs? This is useful when building Whonix for non conventional platforms like POWER. Can this be easily selected during build time?
All, don’t know. But more platforms, yes.
Even if the answer for that platform is “yes”, could be that Tor won’t start if Whonix is using Tor configuration features only available in a newer Tor version. Maybe %include is unsupported in Debian buster version. I don’t test that since design was decided as per above post and compatible with all platforms not a higher priority goal.
Currently no. But nobody ever noticed for any unsupported platforms. Possible to add code to skip that Tor package from deb.torproject.org download code.
2. Use latest stable in TPO repository and allow testers to use the Tor nightly build in Whonix ™, with bug reporting bug to TPO
Advantages: Latest features, better security, improved Tor Browser compatibility (using SocksPort with flags and even better connectivity performance). 
From the Whonix ™ perspective, these packages are uploaded to deb.torproject.org at random times. These packages are not guaranteed to be compatible with Whonix ™. While there are no security concerns, these packages could break a system’s apt-get package management (due to incompatible dependencies) or connectivity, in case Tor refuses to start. This can arise due to a configuration incompatibility in a newer version of Tor, or for other reasons such as systemd or apparmor related changes.
This version is the first alpha release of the 0.4.7.x series. One major feature is Vanguards Lite, from proposal 333, to help mitigate guard discovery attacks against onion services. It also includes numerous bugfixes.
Major features (Proposal 332, onion services, guard selection algorithm):
Clients and onion services now choose four long-lived “layer 2” guard relays for use as the middle hop in all onion circuits. These relays are kept in place for a randomized duration averaging 1 week. This mitigates guard discovery attacks against clients and short-lived onion services such as OnionShare. Long-lived onion services that need high security should still use the Vanguards addon (GitHub - mikeperry-tor/vanguards: Vanguards help guard you from getting vanned...). Closes ticket 40363; implements proposal 333.
I wonder if it would make sense to install anon-shared-build-apt-sources-tpo by default, and to have Whonix Gateway depend on the exact tor version that’s currently bundled in the latest stable Tor Browser release?
Whenever the Whonix Gateway tor version is out of sync with the mainline Tor Browser tor version, it’s a potential fingerprinting hazard.
I am not saying it shouldn’t be done. Only linking to previous thoughts to consider before making such a big change.
What versions are provided by deb.torproject.org is not being kept fully synchronous. It’s contributed, maintained by Peter Palfrader (also a Debian developer) last time I checked. Great year long service btw! However, The Tor Project does not orchestrate TBB and deb.torproject.org releases being always having the same/compatible versions.
By hard coding a version dependency it would break the build process as soon as deb.torproject.org changes. When deb.torproject.org is changed is unpredictable form my point of view.
Indeed. A price to pay for Tor / Tor Browser isolation. But I don’t think it can be resolved without having Tor Browser + Debian tor package being properly maintained in packages.debian.org (which is unfortunately highly unlikely for Tor Browser, not happening for a decade or so) while deb.torproject.org can have different versions (mostly Tor Browser using a newer version than available in deb.torproject.org but it could also happen vice versa) because it’s all different development teams and release cycles, deb.torproject.org, Tor core, TBB.