Would the following be a horrible idea for std?
format!("{:#?}", 10_000_000) == "10_000_000"
On the surface, seems like an easy QoL improvement. But this burns # for numbers, and changes debug format.
Note that, as this is Debug, we don't need locale-specific thousand separators.
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 (edit: it looks like binary formatting can't be combined with debug formatting? weird...)?format!("{:#b?}", 54321)
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).
Separators seem reasonable to me.
I'd even go further in Debug, and consider detecting things like showing 268_505_089 as 0x1001_1001.
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 