As long as any change is just increasing the possible max values, the default shuffles should be ok. Well, except if the range of RANDOM was changed, but that doesn't seem to be the case. It still seems to resolve to between 0 and 32000 or so. Can anyone clarify, is RANDOM 0 to 32000 or is it 0 to 32767 ?

Anyway... Here are the other variables I've been able to find. Some work fine in upper case, some don't. So lowercase used for consistency. Variables with no values, or values beginning with 0, are treated as 0 and can cause weird behavior.

Usage: (-)variable=#
Where # is a positive integer.

length
Track size in bytes.

duration
Track duration in milliseconds.

offset
Offset of first valid MP3 frame, i.e., number of bytes before first valid frame. wave=0, wma=?

samplerate
Track's samplerate in Hz. wave=0, wma=?
Possible values for MP3s: 48000, 44100, and 32000 if stereo. 24000, 22050, and 16000 if mono. The vast majority of MP3s are going to be 44100.

tracknr
Value of "Track #" field.
Track numbers beginning with 0 cause weirdness.

file_id
Value of "Track #" field.
Track numbers beginning with 0 cause weirdness.

pin
Pin number assigned to track.

play_count
Number of times played. Similar to PLAYS, but the value of play_count is the actual play count, where the value of PLAYS appears to be (play count)*(-1). So "shuffle0=Least played,-play_count=1" is the same as "shuffle0=Least played,PLAYS=1"

play_last
Number of seconds between 00:00:00 UTC 1/1/1970 and time last played. Similar to TIME, though TIME = (current time)-(played last)
Functionally "shuffle0=Least recently played,-play_last=1" and "shuffle0=Least recently played,TIME=1" are equivalent, even though the values are not the same.

fid=1
Track's FID number.

bpm=1
Track's beats per minute as calculated by player.

Are there any others? Is there one that evaluates to current time?