VFP handles collating sequences in a superb manner, but there are a few things to be aware of, and couple more to wish for:

- All sequences except "machine" use double byte key values internally.
- Non-machine sequences are case-blind (i.e. the uppercase and lowercase of the same letter have equal weights).
- Non-machine sequences are not Rushmore optimizable (not sure of this information).
- The help still mentions only Western collating sequences, though others are available; maybe other lists of collating sequences are mentioned in localized versions of VFP (in Help, there's an index on "RUSSIAN collating sequence" which points to the "SET COLLATE" topic which doesn't mention Russian at all). I'd rather like to have them all listed in Help.
- Set Collate command is global - it affects all the indexes created from that point on. There's no option in the Index command to have a tag-specific collating sequence. A "Collate" clause would be very welcome, like this:

INDEX ON eExpression TO IDXFileName | TAG TagName [OF CDXFileName]
[FOR lExpression]
[COMPACT]
[ASCENDING | DESCENDING]
[UNIQUE | CANDIDATE]
[ADDITIVE]
[COLLATE cSequence]

This can be achieved already, by issuing specific Set Collate < sequence > before each Index command while indexing. It worked flawlessly in 2.6.

With the advent of VFP, a restriction was imposed to allowable combinations of table's codepage and collating sequence: now it's not possible to have a table with CpDbf() of 1250 and a tag with collating sequence "GENERAL" for it, or a table with CpDbf() of 1252 and collating sequence "Slovak" (which caused even Tastrade to miserably fail on me in each of the versions, because I've had a Collate=Slovak in config.fpw). This restriction should either be removed, or aided. Possible aid (besides the proposed addition to the Index command above) would be another column in the Index tab of the table designer form, which would contain a dropdown combo with allowable collating sequences for table's codepage. It would have to force a "machine" sequence for all key types except character, because using double-byte key values on integer, numeric, date and other data types may lead to unpredictable results (usually seen as failing Seek()s).

I promise to recompile and rephrase this and post it to FoxWish after I get opinions from any concerned people here.