What’s the Next Major Upgrade Bitcoin Actually Needs?

[Barrykbest]

Remembering Taproot, it was huge for privacy and scripting, but what’s next? Do you think soft forks like Ark, or Layer 2 solutions like Fedimint and Lightning improvements, are the next step or should Bitcoin stay conservative with upgrades?

[ABCbits]

Remembering Taproot, it was huge for privacy and scripting

IMO privacy offered by Taproot isn't that big, since the actual privacy improvement mostly are about,
1. Not reveal part of script path that isn't used to spend the UTXO.
2. It's Schnorr Signature (usually for multi-sig) aggregate multiple signature, where individual key isn't revealed.

Do you think soft forks like Ark, or Layer 2 solutions like Fedimint and Lightning improvements

Ark generally categorized as Layer 2 rather than part of Bitcoin protocol that require soft-fork to be activated. And in strict definition, both Fedimint and LN aren't part of Bitcoin protocol/network.

[Liocen]

Taproot was a huge step forward for Bitcoin by breaking the old paradigm, not only increasing privacy, but also opening the door for future scripting and Layer 2 innovation.

In my opinion, Bitcoin’s core Layer 1 should always be kept as stable and secure as possible. This is the core design philosophy of don’t break what already works.

However, new ideas such as Ark, Fedimint, and improved versions of Lightning should be tested and implemented at the Layer 2 level. This will open up new doors for the Bitcoin network.

This way we can innovate while maintaining the stability of the base layer.

So, the future of Bitcoin is likely to be
Conservative base, experimental layers.

In this way, stronger privacy, scalability, and community-driven solutions will gradually emerge based on Taproot.

[Ambatman]

However, new ideas such as Ark, Fedimint, and improved versions of Lightning should be tested and implemented at the Layer 2 level. This will open up new doors for the Bitcoin network.

Open up new doors? No they should stay and  remain on layer two.
There's a reason they are been run at layer two and that's because there's always a sacrifice.

should Bitcoin stay conservative with upgrades?

I believe it should be Simple and Money like
Organic upgrades not half assed rushed for the sake of upgrading.

[d5000]

I'm "shipping" for two major upgrades:

1) Covenants. Basically that means that you can set up conditions for payments. While that is already possible to some extent, once the person you paid the coins to has "unlocked" them with their private key, they can do what they want with them. In some cases however you would like to put a condition one step further, i.e. that the person you paid has also to follow some rules to spend the coins. An example: They must spend them to a certain group of addresses.

Some sidechains, Lightning and also Ark would enormously benefit from this feature. Some people will now yell "Bitcoin isn't Ethereum!!!". But covenants would still not enable infinite loops like Ethereum does, and if we had better L2s, then the scalability problem would have been practically solved and Bitcoin is finally really ready for global mass adoption.

An explanation from Bitcoin Magazine:

[...] if a Bitcoin script currently restricts who can spend a coin by demanding an authorization proof, i.e. a cryptographic signature, or when it can be spent, i.e. after a timelock expires or the spender can show the preimage to a hash, a covenant script restricts how it can be spent, i.e. to who, how much to which person, etc. A covenant script can even restrict a coin so that it must be spent to another covenant script.

There are several proposed mechanisms which can be seen here in this wiki page with support from developers.

2) Utreexo. Storing the UTXO set in a different way, instead of all UTXOs being stored fully, only an "accumulator" composed of hashes is stored. This would lower the burden on full nodes, above all if we consider the bloat of the UTXO set due to protocols like Ordinals and Stampchain which create a lot of unspendable or dust outputs which would clutter the UTXO set forever.

I think this is a part of the final solution to the spam problem too.

There are draft BIPs with proposed numbers 181 to 183. I've also started a thread about that feature.