so delegating such by now very very edge cases to non standard C seems fine, i.e. seems to IMHO not change much at all in practice

and C/C++ compilers are anyway full of non standard extensions and it's not that CHAR_BIT go away or you as a non-standard extension assume it might not be 8

Given that Wikipedia says UNIVAC was discontinued in 1986 I’m pretty sure the answer is no and no!

Edit: I see TFA mentions them but questions how relevant C++ is in that sort of embedded environment.

For some DSP-ish sort of processors I think it doesn't make sense to have addressability at char level, and the gates to support it would be better spent on better 16 and 32 bit multipliers. ::shrugs::

I feel kind of ambivalent about the standards proposal. We already have fixed size types. If you want/need an exact type, that already exists. The non-fixed size types set minimums and allow platforms to set larger sizes for performance reasons.

Having no fast 8-bit level access is a perfectly reasonable decision for a small DSP.

Might it be better instead to migrate many users of char to (u)int8_t?

The proposed alternative of CHAR_BIT congruent to 0 mod 8 also sounds pretty reasonable, in that it captures the existing non-8-bit char platforms and also the justification for non-8-bit char platforms (that if you're not doing much string processing but instead doing all math processing, the additional hardware for efficient 8 bit access is a total waste).

https://man7.org/linux/man-pages/man3/fgetc.3.html

fgetc(3) and its companions always return character-by-character input as an int, and the reason is that EOF is represented as -1. An unsigned char is unable to represent EOF. If you're using the wrong return value, you'll never detect this condition.

However, if you don't receive an EOF, then it should be perfectly fine to cast the value to unsigned char without loss of precision.