This separation is aimed at reducing the noise in the Core repository, which is primarily focused on non-consensus changes. Although optional, this new repository serves as a testing ground for significant modifications before they are formally proposed for activation within Bitcoin Core. This step can be advantageous if it aids the process for any particular change.

The discussion extends into the implementation of LN-Symmetry and the potential limitations of using APO—Alternative Public Outputs—for this purpose. APO represents a restricted development path that introduces new key types and a set of sighash flags that lack an easy upgrade path; adding new features would require the creation of additional new key types. There is an open pull request against APO that proposes a different design for these sighash flags, addressing the issue that they should commit to the control block or merkle path in certain modes. This highlights a broader design space for sighash flags and brings attention to their limited direct upgradeability.

In comparison, CTV—CHECKTEMPLATEVERIFY—offers a more confined design space with a clearly defined output commitment template as presented in BIP119. Combined with CHECKSIGFROMSTACK (CSFS), CTV can facilitate the same commitment used in the LN-Symmetry implementation referenced by @instagibbs. Deploying CTV and CSFS allows for a period of observation and analysis, providing valuable insights into potential additional sighash modes that could be beneficial for future Tapscript key versions. This methodical approach emphasizes the use of small, fundamental building blocks to support second-layer enhancements and lays the groundwork for ongoing discussions about subsequent improvements.