Most OSes use base 10 for file sizes, Windows is the only exception

An "exception" that still had over 75% of market share, last time I checked.

Of course Apple and Unix users will all be confused anyway because their OS uses base 10.

Really ? IMO that depends on the context and tools used. This is my world (sorry I'm a CLI guy):

$ ls -l test.pdf # shows bytes by default
-rwxr-xr-x 1 dregad dregad 430743 Nov  6 12:48 test.pdf*
$ ls -l -h test.pdf # "human" translates to KiB
-rwxr-xr-x 1 dregad dregad 421K Nov  6 12:48 test.pdf*
$ ls -l -h --si test.pdf # need an additional flag to display in powers of 1000
-rwxr-xr-x 1 dregad dregad 431k Nov  6 12:48 test.pdf*

And it's also worth mentioning that if you set upload_max_filesize or post_max_size to 100M in php.ini, that actually means 100MiB (reference).

But let's leave the opinionated debate of whether file sizes should be measured in 10^3 or 2^10 based increments aside. We have settled on IEEE 1541 binary units for MantisBT in 0027700, and I personally don't see any compelling reason to change that. What matters is that we are reporting the numbers as KiB which is unambiguous (unlike KB which can be misinterpreted) - and if you hover your mouse above them, you'll even see the actual size in bytes.

In any case, I don't think that's the point of your request. If I understand correctly, you just want $g_max_file_size to be displayed in a "human-readable" format, e.g. 1024 bytes as 1 KiB, 1'048'576 bytes as 1 MiB, etc, which should be feasible fairly easily by adapting print_max_filesize() function to use a dynamic unit depending on the config's actual value. Something like this:

    $t_units = ['bytes', 'KiB', 'MiB', 'GiB']; # Should be localized 
    for( $i = 0; $p_size >= $p_divider * 0.9 && $i < count( $t_units ) - 1; $i ++ ) {
        $p_size /= $p_divider;
    }
    echo get_filesize_info( $p_size, $t_units[$i] );

Is this what you expect?

As a side note, are you really allowing 100 MB file attachments !?