Quote

if BTC doesn't increase the supply cap

It will not. Because it will be a hard-fork, leading to just another altcoin.

However, you don't need changes in supply. All you need, is just changing proportions. So, you can have a subnetwork, which will use different amounts, and it can work on top of Bitcoin, as long, as you can make it backward-compatible, and represent on-chain amounts correctly.

For example: Lightning Network introduced millisatoshis. Every on-chain satoshi is converted into 1000 millisatoshis, and then, it is converted back from 1000 millisatoshis, into a single satoshi. However, there are no technical barriers, which would stop people from introducing non-linear dependencies, where you could have 21 billion coins limit, and where it could be possible to create more coins, out of thin air, which would exist only in a particular L2. So, for now, we have a constant 1:1000 peg. But: it is possible to make "a different tail supply L2 network", which will have different rules.

Quote

Miners not getting paid enough rewards in transaction fees

Minimal on-chain fees are set into 1 sat/vB as a de-facto standard. It was not changed for a long time, and it seems, that it will not change in the future. Assuming 4 MvB fully filled blocks, it means getting at least 0.04 BTC per block in fees. So, after next halvings, the basic block reward will go below 0.04 BTC, but fee rules may be left unchanged. Then, is 0.04 BTC per block not enough, if the basic block reward will be lower than that?

Quote

We know that Bitcoin L1 is not going to scale up any time soon.

Some people underestimate changes like full-RBF. If you have two on-chain transactions, where one is spending coins from the other, and you have a chain of unconfirmed transactions, then you can batch them, and increase feerate, without adding new coins. If you have one transaction taking 1 kvB, and another transaction taking another 1 kvB, then by batching both transactions, the batched version could take for example 1.5 kvB, which would also bump fees, so miners would have an incentive, to include batched version instead.

I think sooner or later, we would need something like "batched mempool explorer", where instead of seeing, that "we have 650 MB transactions waiting", people could see for example "we have 400 MB transactions waiting, if all of them will be batched".

Quote

Bitcoin L1 stays at the same fee rates as they are today, but does not achieve mass adoption.

Why do you think, that "fee rates" is the barrier? For example, I sold almost all of my BTCs, because of new KYC/AML rules, being enforced since 30 December 2024. I used BTC in 2019-2024, sometimes fees were higher, sometimes lower. But usually, it was not a big issue to use Bitcoin.

Also, I tried LTC for a while, when fees were higher on BTC, but finally, it turned out, that if I would just stick with BTC instead, then it would be much more profitable for me, even if I would pay higher fees, because of that.

Quote

by using some project on L1 like Ordinals, Runes

It is good, that fees are stopping some users from pushing Ordinals on-chain. It is by design. And more batching should be also implemented, to let regular transactions compete with Ordinals, by using optimizations like cut-through.

Quote

Notice how "increase the supply cap and print more bitcoins" is not an option.

People will try it anyway. However, fortunately, burning coins is easier, than making them out of thin air. Which means, that people should be ready to burn coins, if tail supply supporters will somehow produce too much. And fortunately, making it mandatory to burn everything, which will be overprinted, is a valid soft-fork.

Quote

Nobody who owns Bitcoin will agree to let it become a money printer.

You don't need 100% network support, to locally increase the supply.

Quote

Block size limit (on Bitcoin L1) got increased.

This will not happen, because then, it would be possible to push more on-chain spam, without making it easier, to push more regular transactions.

Also, Ordinals blocked any block size increase proposal for a while. And "quantum resistant addresses" will block it even further.