:: Is it "right" to break existing applications, cause gbak to
:: fail to restore backup files, etc.? Yes, if we were just

It would depend on the options of the database. If Gbak does a overwrite it
would come with that ok. If they user tries to restore into a different db
(ie flag set) then yes it should fail. Doesn't seem like a major problem to
work within.

:: introducing variable length characters, I might - probably
:: would - argue for following your eminently sensible rules.
:: But, we've got nearly a decade of different behavior.

This behaviour though is - without meaning offense - quite flawed and should
be fixed no matter how long the behavoiur has been there. Im not aware of
any other DB that treats the x in varchar(x) as actual storage space. Its
not VarBytes, its VarChar. This really hurts database portability, breaks
frameworks that rely on reading this info from the database, and leads to
bugs in code because the database has potential to return more data than
clients are expecting based on information of the field. This is very bad
bahaviour and seems merely a problem with its implementation relating to
Unicode.

Considering the additional fact that Unicode is probably newer thatn 10
years, and that most people in fact are not using Unicode is both why its
probably not been raised much before, and also why it should be fixed now
rather than later as it will affect fewer people.