This sounds pretty good, yes. There are some details I need to think about a little more but it looks very close already and probably covers what I already had. It would miss spinloops which don't spin, but it may not be as important since there won't be a need to 'infer' the activity of the other side from a non-spin case.
The part I want to think about is the VBL marking / instance ordering because I don't think it will work as expected due to the lack of a stable VBL:FRAME ratio but more significantly, the large number of spins which occur on each frame or VBL (some spin sites in my program will occur hundreds of times each display frame). There is probably a better way to identifty/sort them, perhaps by a combination of 'user frame' (e.g. r_begin label) the global cycle counter since CPU/DSP are in lockstep... so both sides of the spin could be identified as a single cooperation...
Since I didn't have this info before, any such bonus can't be bad however it may work :-) but I think some small changes would make it immediately more useful so I'll think more about that part before responding. I'll get back to you soon :-)