>> In order to avoid that logic, and cause more format specifiers to result in str-like behavior, we'll need to implement an __format__ somewhere (IntEnum, I guess) that makes the "int or str" decision.
> 
> If this is the way format is supposed to work, then I'll add __format__ to IntEnum with simple logic that says if not 
> letter format code is present, use string formatting, otherwise use int formatting.  

Yes, that's exactly how it's supposed to be used, and why __format__
exists at all.

> That should be future proof.

Agreed.

It does mean that a few things that look like int format specifiers
won't be, but I don't think it's a big loss.

For example, '+' only makes sense on an int, but with your proposal it
would be a str format specifier:

>>> format(42, '+')
'+42'
>>> format('42', '+')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Sign not allowed in string format specifier

Again, I don't think any of these would be a big deal. But it does mean
that there are places that could take an int that can't take an IntEnum.