As per #46440 (comment), rather than adding new overloads API review opted to take the breaking change in how standard vs custom numeric format strings are differentiated.

As per the new rules, standard numeric format strings would be identified by an ASCII alphabetical character followed by a sequence of ASCII digits. If the number of digits doesn't fit into a System.Int32, it will throw.

This is a breaking change in that today 42.ToString("G999") is interpreted as a "custom numeric format string" and will print G999 as will other values such as 42.ToString("G100") printing G142. Moving forward, these would be interpreted as "standard numeric format strings" and would be treated as the G format specifier with the respective number of digits, thus printing 42.

Likewise, today 42.ToString("H999") is interpreted as a "custom numeric format string" and will print H999, while 42.ToString("H99") is interpreted as a "standard numeric format string" and since H is not supported, it throws. Moving forward, both will throw since H is not a supported "standard numeric format string". This leaves it open to be used in the future if necessary.

Format strings, like the following, would continue to be interpreted as "custom numeric format strings":

• start with any character that is not an ASCII alphabetical character (such as $ or è)
• start with an ASCII alphabetical character but which are not followed by an ASCII digit (such as A$)
• start with an ASCII alphabetical character, followed by an ASCII digit sequence, and then any character that is not an ASCII digit character (such as A55A).

For users who want to maintain the previous behavior (that is where 42.ToString("G999") was intentionally meant to return G999) they can explicitly single quote the first character (that is 42.ToString("'G'999")). This will work on .NET Framework, .NET Core, and .NET 5+

The Definition of Done for this includes (but is not limited to):

• Commenting on this issue with a test matrix of method pairs for round-tripping values through formatting/parsing
• Commenting on this issue with the full list of APIs that will be affected with new behavior
• Sharing that information with partner teams for advance notice before merging into master
• Creating a breaking change document issue
• Updating existing documentation for the affected APIs to reflect the changes