Given that even phones have 64 bit CPUs at this point, it might be time to switch to 64 bit timestamps, with higher sub-sample resolution. A 48:16 timestamp format would have a number of advantages over the current 24:8 format:
Wrapping at 192 kHz would occur after 46 years, as opposed to every 87 seconds, so we can just ignore that, meaning...
No special care (macros) needed for timestamp arithmetic and comparisons
Long delays (event scheduling, envelope times etc) will no longer be problematic
Accuracy should be enough for implementing granular/BLIT oscillators with no audible artifacts due to timing errors
64 bits is plenty of space for alternative timestamp formats, such as measure:beat:tick, SMPTE etc, perhaps with the format encoded in the high bits
On the downside, that would of course reintroduce the need for special care when comparing and operating on timestamps
Other formats may be of interest, for a bit of extra resolution, but the wrap time quickly becomes a real issue;
32:32 wraps ever 6.2 hours, which is problematic in common applications
40:24 wraps every 66 days, which would be a problem in embedded systems, arcade games and the like
Given that even phones have 64 bit CPUs at this point, it might be time to switch to 64 bit timestamps, with higher sub-sample resolution. A 48:16 timestamp format would have a number of advantages over the current 24:8 format:
Other formats may be of interest, for a bit of extra resolution, but the wrap time quickly becomes a real issue;