Wouldn't that scheme get a bit unwieldy for the 48 (or more!) timers mentioned in the OP?!

For such large numbers of timers, it might be better to have the ISR just generate a 'tick', and then the main loop implement the "application timers".
A linked list can be used to advantage here:

Initially, all 48 (or whatever) timers are idle, and linked into a "free" queue;
When a timer is started, it is moved into the "active" queue;
Each time round the main loop, the "application timer" handler walks the "active" queue, updating all the timers in it (ie, all the active timers)
When a timer expires, its expiry flag is set, and it is moved back to the "free" queue.

Note that this does not require the use of dynamic memory allocation: the required number of timers can be defined at compile time - at runtime, it's just a matter of linking them into the "free" or "active" list.
(In fact, you might not even need the "free" queue at all).

Another advantage is that changing the number of timers is easy - you don't have to update hard-coded entries in the ISR!