yeah, the event limit we are talking about, are for events that need to be stored.
so thats things like the midi notes/cc on a track and any automation ‘data’ (e.g. if your automating an fx parameter that needs to be stored too)
anything that is calculated (e.g. and LFO/arp) does not use extra events (for storage) , it creates ‘events’ on the fly.
(as you correctly mention, consolidating turns these calculated events into stored events and so means that now are subject to the event limit)
note: of course, there are other limitations, like cpu (hence one reason we have limited # of fx slots) and the amount of data that can be sent over USB/midi din.
I think the event limit is mainly problematic when used with things creating a large number of continuous events or very large projects( with lots of notes, and large numbers of tracks (*) )
(*) i seem to remember some users doing this, as they want to have their entire live set as one project, so they could smoothly transition from one piece to the next as projects could not be loaded without disturbing the flow. (we have seen related feature requests for being able to ‘load projects on the fly’, ‘sequence projects without stopping’ etc )
its a very reasonable thing to want to do. but unfortunately, i think the pyramid was not really designed to do this - and is not really possible to retro fit.