Agreed.

My programming intuition sounds the alarm when I see solutions with a number of unknown downstream consequences. I don't like code with unknown risks.

At a minimum, features can be tested for several years on for example Liquid Network and be evaluated there.

Among the claims of lower L1 fees, I don't trust such claims for several reasons. Tx fees can already range from $1.5 to the tx's upwards of $200 that were seen for a week right after the halving. This tells me that the tx fee pricing is largely dependent on the willingness of participants to pay a certain amount. If there is a willingness to pay high fees, then we can improve the bandwidth all we want on L1 without achieving low fees.

As far as the solutions involving increased efficiency for exchange transfers, I doubt that they would make much of an impact, if exchanges want to use them.

For the other proposals I am also unconvinced that there will be actual increases in L1 efficiency. They may or may not be significantly helpful.

My main concern is the ability to whitelist future addresses, i.e. blacklisting all addresses outside of the whitelist. It is not inconceivable that governments at some future point, in an attempt to hinder the competition against CBDC's, may decide to require exchanges via regulations to apply whitelisting schemes, to lock bitcoin within an approved framework of future addresses. Even if such regulations are introduced and then abolished at a later date, the whitelisting protocol would already be in place. If central planners can abuse a mechanic on L1, I would rather see such a mechanic on L2-L3.