In my opinion packet switching is an idea that would have been inevitable once the technology to support it is in place. The real important idea of the Internet is the insight that the envelope should be independent of the data it contains.
I say this because I work with specialized equipment that uses RS-232 serial protocols for communication, and despite many decades of examples available of "the right" way to do it (e.g. OSI model), engineers continue(d) to not understand this lesson and design ad hoc protocols that don't respect this division of concerns and which suffer for it. Even in IP protocols designed to modernize this to wrap the RS-232 serial packets in internet packets, they repeat the same mistake(s). That is, in the midst of having to deal with a more complicated problem for serial protocol to IP protocol conversion because the original format didn't clearly distinguish envelope from data, they compound the problem by mixing levels in the new protocol.
For example, writing IPv4 into the standard for a proprietary an Application or Session level protocol even at the same time as our network is banning IPv4 and requiring IPv6, but the protocol is not even defined for IPv6 addresses. When it should be agnostic to IP level concerns entirely. (The engineers said, while designing the system, "well .1 is going to be this piece of equipment, .2 is going to be the other side, if it's blah blah blah it's .3, etc.")
People keep repeating this mistake at all layers of the stack because they fail to see different layers as managing different sets of concerns and want to treat it as a monolith.
A very recent and high level example of this is how the Matrix protocol was architected. By defining all the message formats in terms of JSON-over-HTTP it makes it difficult to only use part of the protocol and not all of it, and makes it difficult to use it over alternative transports since the assumptions of HTTP idioms are baked all the way down.
This is a great example of what I mean. They had to swap for formats that were designed to be equivalent to HTTP and JSON in order to not have to rewrite large parts of the protocol. And that project was just a prototype that was never productionalized to my knowledge.
I say this because I work with specialized equipment that uses RS-232 serial protocols for communication, and despite many decades of examples available of "the right" way to do it (e.g. OSI model), engineers continue(d) to not understand this lesson and design ad hoc protocols that don't respect this division of concerns and which suffer for it. Even in IP protocols designed to modernize this to wrap the RS-232 serial packets in internet packets, they repeat the same mistake(s). That is, in the midst of having to deal with a more complicated problem for serial protocol to IP protocol conversion because the original format didn't clearly distinguish envelope from data, they compound the problem by mixing levels in the new protocol.
For example, writing IPv4 into the standard for a proprietary an Application or Session level protocol even at the same time as our network is banning IPv4 and requiring IPv6, but the protocol is not even defined for IPv6 addresses. When it should be agnostic to IP level concerns entirely. (The engineers said, while designing the system, "well .1 is going to be this piece of equipment, .2 is going to be the other side, if it's blah blah blah it's .3, etc.")