I assume this would also apply to floats? i.e. format!("{:#?}", 1_234.567_8) == "1_234.567_8"? Though I'm sure that's debatable...
How would this play with hex and binary formatting? What would be the result of format!("{:#010x?}", 123456789)or format!("{:#b?}", 54321) (edit: it looks like binary formatting can't be combined with debug formatting? weird...)?
It's bad enough that x? exists, supporting b? too would be even more painful . Especially since x? is a core internal API that external "number" types cannot support (other than by converting themselves into a series of u8 and formatting them into the formatter, but that breaks other things like width).
They should probably use eight-bit groups, like 0b_01101111_00010000, and four hex digit groups like 0x_a13e_feed, so that the reader can see bytes (there are two hex digits to a byte, but an underscore every two digits seems annoying, so hex would group 16-bit words instead).
Would it be possible to extend the format spec? So you could write something like "{:_3}" for a thousands separator, "{:_4x}" for typical hex grouping, or whatever makes sense in your domain.
Some countries group decimal digits in sets of 4 or 2 instead of 3. Though I think 3 is also recognized just due to it's prevalence, so I wasn't going to mention it...
...but it is another argument for including something like this, or at least leaving the door open.
Given that I thought of something to this effect just the other day when I noticed dbg! doesn't include a separator (the macro uses {:#?}), I fully support this