Having had to implement VNC authentication a while back, I can assure you that it is not agnostic, and you have inadvertently revealed the reason for that in your own post.

Since the user password is used as the DES key, and DES key size is limited to 56 bits (plus 8 parity bits), your key can only be up to 7 8-byte characters long. However, since ASCII only uses 7 bits, you give an 8 ASCII character key instead, and the unused 8th bit of every byte is simply discarded. If the password is shorter than 8 characters, it's just padded with zeroes.

Many VNC clients and sometimes even servers allow you to enter a longer password, but as long as they're connecting to a the standard auth implementation, they'll actually truncate your password to 8 characters during operation. Yes, even RealVNC's client does that when only the standard auth is possible. It will warn you that the connection is not encrypted, but it won't let you know that your password just got slashed.

Defining alternate authentication schemes is possible, but require VNC clients to add support for those. RealVNC has simply defined one of those. So everyone should just implement that right? I think you'll find out the reason why the standard auth is still so prevalent if you spend some time trying to find any implementation documentation for it.