So, Bitcoin is a multi-layer system already.

I am going to make a rather monotonous point about second layers. "Second layers" in bitcoin are everywhere. If you have wallet software: you are using a "second layer".

If you ever played with the Bitcoin node software itself (or any derivative), you'll notice something: it's an application-specific database. The application it is does specifically is performing cryptographically-secured transactions with a native currency and transaction format and settles transactions using a really sophisticated singly-linked-list type data structure. The reference implementation also has a GUI interface, but technically, you can just run the node (bitcoind) and use other wallet software. The node software provides a low-level RPC interface (RPC = Remote Procedure Call) so software applications can inspect the state of the transaction database and also deliver transactions to it and have the node software to deliver the transactions it receives.

A whole system of any sufficient complexity is going to have multiple layers. However, each layer will have different responsibilities. This is good system design and will be inevitable particularly when you are dealing with P2P network software (in this case, the two layers are clients and servers.)

While this is not necessarily surprising, it is also good system design where parts of the system can be developed by specialists for each layer. We know for a fact that there are very few people in the world who understand how to build P2P consensus-based transaction systems. Given how the Bitcoin Core wallet looks, you could assume that they are not interested in further developing it to level other wallets are at. This is not a bad thing; hardware wallet software or software like Electrum is much better in terms of UI anyway.

Developers who work on lower-level software like Bitcoin have to make very big decisions; you have to give them credit because writing rock-solid software that has the goal of lasting for years is no easy task. The important thing though is that those who do work on lower-level software will have to live with their mistakes, many of which can just be easily deferred to higher layers.

I learned this from experience as a software developer. As an application developer myself on an extremely complex long-living system, poor design decisions. There is also no end to the "it needs to do this AND NOW" mentality to lower-levels when higher layers can solve problems better.

So, what are some second layers (i.e. applications) and what do they solve that Bitcoin consensus software development should not solve?

Electrum, as an example, offers many tools and techniques to:

generate private keys, public keys and public addresses
Making complex transactions, such as Child-Pays-Parent or Replace-By-Fee much easier
Integrates a nice UI to make these things easier to understand

Electrum developers certainly have their own reliability issues to solve, but making a system is one thing and then making it user-friendly and functional is a completely separate thing.

One major problem that Bitcoin Core developers are not going to handle is private key management properly.
(On some levels, they do.) Private key management, done in a user-friendly and secure way, is actually pretty hard to do well. I personally deal with lots of private keys: PGP keys, SSH keys, keys for decrypting password databases. Now I have to also deal with Bitcoin private keys. For Bitcoin, I do rely on my Trezor. The private key is obfuscated by many layers that required those developers to not only understand the Bitcoin protocol but also to do hardware engineering and embedded software development to build it out.

Private key management is not a consensus protocol issue. It's a second layer/application issue.

Wallets that can build, sign and deliver transactions on the Bitcoin network, as well as provide things like fee estimations, are second layers. They are applications on the Bitcoin protocol to

make stuff easier to do with Bitcoin and,
to create novel applications over Bitcoin.

One significant type of wallet also includes a way to transact without the Bitcoin network involved. They are called exchange wallets. Exchanges record transfer of ownership probably in various ways, but mostly involves a database, hidden from the public that records who owns what and at what times. (Not exactly the decentralized future we so want from Bitcoin!). Transfer of ownership is recorded without actually involving the Bitcoin blockchain until the bitcoin needs to leave their network.

Exchange wallets are a second layer which provide applications that Electrum and Trezor don't:

If the coin remains on/is "commited" to the exchange wallet, transaction speed is blazing fast (no confirmation times!)
On something like Coinbase, you can send coin to an email address, because the coin stays on the wallet. No crazy address strings!
The tradeoff (the intended consequence) is that by exchange wallets securing the private key, you don't, but you still don't control the key. (MtGox ... sigh)
The company that manages the exchange wallet has certain liabilities potentially (like losing customer funds, which they have a fiduciary responsibility towards)

The Lightning Network is just like the exchange wallet:

If the coin remains on/is "committed" to a payment channel (basically a mutli-signature address with someone on the Lightning Network, that uses Bitcoin consensus rules to ensure that coin committed to channels will not be stolen by the counterparty) transaction speed is blazing fast when payments are routed to recipients (no confirmation times!)
Unlike exchange wallets, all parties are anonymous to each other (does not/should not require KYC, like exchange wallets require.)
The tradeoff off is still just a problem of private key management like other wallet software.
Lightning wallets are just Bitcoin wallets that create multi-sig transactions on the Bitcoin blockchain with pre-designed smart contracts that are transparent, unlike exchange wallets.

There might be conceptual issues with the Lightning Network, but if you don't find doing exchange trades in an exchange wallet or even establishing private channels that already use Bitcoin consensus rules and tooling, then the Lightning Network is not really absurd at all.

The point I want to make is this: systems will always have growing pains. Bitcoin consensus protocol developers have decided to not solve scalability issues, encouraging users to adopt more sophisticated second layers. As of this writing, there are users that abuse the Bitcoin network (re: Coinbase, who doesn't batch transactions and is not using SegWit more.) But, Bitcoin is a system that is meant for the long-term. Design decisions are hard and complex software development must be viewed as a process towards long-term stabilization. Each of the software packages that make up the Bitcoin system are complex pieces: not everything should be solved at one layer or another.

So a bit of advice here: stop worrying about transaction fees, stop thinking some hot new coin will solve all issues present in Bitcoin, and educate yourself on the challenges protocol developers and application developers actually have to face day-to-day.

Well, let's chat about this. I am not a Bitcoin developer; just fascinated about the software and the innovation it brought. If you really liked this, let's use Bitcoin and SegWit. Here is my tipjar address:

3A1QnHKS3SGGH3ng9hsHk8pNS2Fv3P26L3 :