> Can we do this opt-in for future additions to the standard library? Or are we forced to introduce an octet type unrelated to byte if we want networking in the standard?

I don't see how a separate octet type would help. It couldn't actually
be narrower than a byte anyway; it could just have some padding bits.
The strategy on non-8-bit-platforms is to just leave some bits unused
for operations that use char/unsigned char, and that seems fine for
networking too. You don't actually need an octet type.

I still think we should drop support for non-8-bit bytes completely.
Part of the reason is that we now have <simd>, <linalg>, and the list
of standard numerics features only keeps growing. All of these are
freestanding, and it would require heroic effort for any niche
architecture to provide high QoI for such features. Are we really
expecting vendors to create and maintain a decent implementation of
<simd> for their DSPs from scratch?

C++ has become too big for non-8-bit, realistically. Maybe it will
take some more time, but that realization will eventually sink in.