Could Bitcoin Core leave the lockinontimeout parameter choice entirely to Bitcoin Core users and not set a default? There doesn't appear to be overwhelming consensus on the lockinontimeout (LOT) parameter for the Taproot BIP 8 activation mechanism. I know some would strongly argue against doing this but could Bitcoin Core release a version where users are forced to choose between setting LOT to true or false before running the software? Is this technically viable?
Matt Corallo and ZmnSCPxj answered this on the Bitcoin dev mailing list.
Matt Corallo stated:

Bitcoin Core does not have infrastructure to handle switching
consensus rules with the same datadir - after running with  uasf=true
for some time, valid blocks will be marked as invalid, and additional
development would need to occur to  enable switching back to
uasf=false. This is complex, critical code to get right, and the
review and testing cycles  needed seem to be not worth it.
Instead, the only practical way to ship such an option would be to
treat it as a separate chain (the same way regtest,  testnet, and
signet are treated), including its own separate datadir and the like.

ZmnSCPxj added:

Without implying anything else, this can be worked around by a user maintaining two datadirs and running two clients.
This would have an &quot;external&quot; client running an LOT=X (where X is whatever the user prefers) and an &quot;internal&quot; client that is at most 0.21.0, which will not impose any LOT rules.
The internal client then uses connect= directive to connect locally to the external client and connects only to that client, using it as a firewall.
The external client can be run pruned in order to reduce diskspace resource usage (the internal client can remain unpruned if that is needed by the user, e.g. for LN implementation sthat need to look up arbitrary short-channel-ids).
Bandwidth usage should be same since the internal client only connects to the external client and the OS should optimize that case.
CPU usage is doubled, though. (the general idea came from gmax, just to be clear, though the below use is from me)
Then the user can select LOT=C or LOT=!C (where C is whatever Bitcoin
Core ultimately ships with) on the external client based on the user
preferences.
If Taproot is not MASF-activated and LOT=!U is what dominates later
(where U is whatever the user decided on), the user can decide to just
destroy the external node and connect the internal node directly to
the network (optionally upgrading the internal node to LOT=!U) as a
way to &quot;change their mind in view of the economy&quot;. The internal node
will then follow the dominant chain.