sort -t handling with MB_CUR_MAX > 1 is very broken in several ways.
One problem shows up e.g. in LSB 1.3 testsuite on big endian platforms, where
10|567 /tset/LI18NUX2K.L1/utils/sort/sort 18:32:15|TC Start, scenario ref 571-0
520|567 8 23535 1 1|* When -t option is specified, verify this utility use a character as a field separator even if the character is a multibyte character.
520|567 8 23535 1 2|
520|567 8 23535 1 3|Can't handle field separator written in a multibyte chaaracter.
220|567 8 1 18:32:21|FAIL
520|567 24 23535 1 1|* When -c and -t option are specified, verify this utility use a character as a field separator even if the character is a multibyte character.
520|567 24 23535 1 2|
520|567 24 23535 1 3|Can't handle field separator written in a multibyte chaaracter.
220|567 24 1 18:32:29|FAIL
520|567 40 23535 1 1|* When -m and -t option are specified, verify this utility use a character as a field separator even if the character is a multibyte character.
520|567 40 23535 1 2|
520|567 40 23535 1 3|Can't handle field separator written in a multibyte chaaracter.
220|567 40 1 18:32:36|FAIL

But as shown in the attached testcase, it is not just big endian platforms that
have -t broken.

I wonder why this was missed during RHEL3 LSB testing.