> I suspect, but have not verified, that having a bytes version of this code would now require an implementation that shared very little with the str version.

This is not all. The usage model will be completely different too.

* The default formatting should not use str(), but buffer protocol.
* There is no place for floating point.
* There is no place for locale.
* There is no place for 'r' conversion (possible only for 'a').
* It should include the features of struct.pack(), int.to_bytes() and ctypes.
* Padding should be not only by space, but also by zeros (and possibly by other values).
* Alignment (padding to position divisible by some number).
* In addition to padding and truncating should be the ability to raise an exception in case of discrepancy between the needed and actual lengths.
* It unlikely needed attribute access and indexing.
* Builtin format() should not work with this.

As a result, this should be a completely separate formatting mini-language that has nothing shared with strings formatting. Not worth to introduce bytes.format(), it's just confused. Perhaps you should add features to struct module or add a new module. PyPI looks as good place for such experiments. If people will use it, it could be included in the stdlib.