Yes. Since anyone can run any software they want to interact with the Bitcoin network, this idea does seem like a logical development.

It also seems like one of those counter-intuitive anti-fragility things, where the seeming chaos and instability at a micro level will actually lead to a more predictable and stable behaviour at the macro level.

If it became more common for individual nodes to be able to tweak consensus parameters, then I think that would actually lead to more predictable and stable consensus behaviour in the long run. The worst thing that can happen to a node operator is to fall out of consensus with the rest of the network, so individual node operators would be strongly incentivised to develop methods to ensure they can track the status of the network, and deal with any potential consensus forks.

As it stands now, consensus behaviour is based on the specific implementation details of Bitcoin Core. The software is not designed with the assumption that hard consensus forks are a likely event, and when they do happen nodes are not designed to handle it gracefully. The accidental hard form of March 2013 happened because of an obscure implementation detail in the Core software, and was only possible because the software monoculture created a "single point of failure". A more diverse implementation of consensus rules might result in more frequent consensus divergences and orphaned blocks, but each one would be non-catastrophic, and would lead toward a more stable and resilient network in the long run.