(or for those without ipfs: ipns://multiformats.io/multiaddr/)
In my work on Indra, rather than reinvent the wheel, we are using libp2p(warning: ipfs), to handle the majority of the repetitive parts of building a peer to peer network. Theoretically we can even have our peer list mingle in the IPFS peer list with our protocol magic specified, meaning taking down Indra means also taking down IPFS and all the other protocols joining the party.
Ossification is something that has been discussed a bit recently by that shady JL whose name I shall not otherwise complete, as regards to some hypothetical failure of the decentralised community of bitcoin developers to not do something about.
Multiaddresses are an example of how you solve ossification problems. It's a specific case of a general type of architectural pattern that leaves a system open to future expansion without excessive engineering and working for this future hypothetically not ever going to happen wide adoption.
A big part of it is to go through your protocols, and look at them. What is not being stated in the messages that are passed around about the data your protocol handles?
The multiformats page sums it up well. There is a mess of encoding standards for various types of internet addresses, and several of them collide ambiguously and in many of them, there is assumptions made about the application and protocol version, and so on.
These are obstacles to extending a system. They also slow down the process of development of the tech because first you have to learn the invisible stuff that you can't see that is still there and stopping you adding fields or semantics of context or whatever.
The most important thing about any change we make to Bitcoin has to be this:
"Does this specification make it hard to add versioning or variants to the base without retooling everything that touches it?"
If the answer is yes, you have an incomplete protocol specification, that has one or more ambiguous constructions that possibly may conflict with other protocols and may use terrible labels for things that deceive you about what they are for.
Ossification is not the lack of change in a protocol. It's built-in resistance to change in the architecture, which leads to difficult, repetitive code with a lot of scope for errors in the subtly different variants supposedly doing the same thing with a slightly different data type.
I haven't honestly spent that much time thinking about these sorts of quirks in the protocol, but it's one of the reasons why Bitcoin has done so well is that it doesn't make it hard where it matters, most of the time.
Also, we shouldn't anyway be off and racing to find ways to accommodate new L2s on bitcoin, there should be a bit more caution and time spent in testing. The math, right there in the white paper of Lightning Network, states that block size has to increase to afford every human a personal payment channel.
Obviously we still need to improve Lightning Network before we can say what changes Bitcoin needs to make it more viable.
Or we could cut ourself off at the next turn.
Appendix 1: Composition, not inheritance