Repeating timers should continue running if an error occurs, which means it can spam you with errors - this is nothing new, any sane timer implementation does this. With a lot of extra effort, it could try to catch the error and shut down the timer if too many occur, but this is something that adds a lot overhead for little use, imho.
I'll look into the animation frame rate throttle thing.
This is somewhat contrived and unlikely to happen in the wild, but something like
local id = AceTimer:ScheduleTimer(...)
seems to cause duplicate ids about 10% of the time (at least on my setup).
Luckily, while this will cause it to lose track of timers on the short term, it will find them again when they expire and are put into the inactive list.
I'm actually surprised it's as low as 10%! The "start" function (as you've noted) is highly unlikely to ever be used outside of a author-debug situation. But even then, it technically should not be used for profiling.
It is noted here and here how profiling should be done with 2 calls to stop.
Note that debugprofilestart() is more of a global reset than a "start". It is not necessary to call it, ever. In fact, it is probably a much better idea to simply do 2 calls to stop() and calculate the difference, since calling start() will interrupt timing measurements done by other addons.
Unfortunately it appears that 2 people so far have reported issues with timers not cancelling, and I've traced it down to the debugprofilestop call firing the same values for them in a short space of time. Unfortunately, it's obviously not "high precision" enough for them. I'm looking into to re-writing the id system for a new version.
edit: Not sure why I didn't think of this before, but we use a unique table for every timer, so the table id would be perfect. The question is, is it worthwhile to add a load of extra upgrade code to upgrade a lib that's been out as an alpha for ~4 days.
There was no upgrade code needed at all just to change the ids to unique table handles. The handles are opaque on purpose so its possible to change them without any hassle.
The latest version now uses this.
In any case, as long as i'm around, i'll not accept breaking the upgrade path on purpose, even if the old version was just 5 days old. We've not done this in the past, and we'll not start with this in the future. You can never guarantee that this case will not hit some users.
Ace3 trunk always is to be considered "stable", and won't just break on you. Bugs happen, of course, but there should never be a change in trunk that breaks something on purpose. That is a guarantee i've given to people, and i'll keep doing it.