Leads are the limited real HW resource, bc a lead cannot - or only in certain situations - be used by more than 1 event at the same time. Manage these resources programmatically, e.g., by locking them.

What about the case when leads could be used simultaneously? Namely, the overlapping lead sets use the lead as the anode and with the same stim parameters? Does that even work?

save previous data messages received/sent
create some method of flagging which parameters have been changed

AddEvent inherently localizes to all saved areas and lets the transducer deal with selecting which threads it wants.
ClassicDirectTransducer just picks the first fully containing area
Allow users to implement their own StimThread types, all of which must be sortable - IComparable - by some function - the priority scheme. Then in config, the user picks which thread type to map on the percept, and then when an event triggers on an area, all threads the event is to are ordered/pruned by the priority scheme.
Thinking this can take some work off of the transducer(s)? Automatically telling the transducer which thread(s) to deal with?
Does/can this also help w/ how to transduce the event information onto the prioritized thread(s)? Or is it too stimulator-dependent?

Some applications may not need to use the localization functionality, e.g., if never overlapping mapped percept areas or always knowing which area(s) to be called given an event.

Basically, make an AddEvent() that is just like an interrupt/callback on a saved area, e.g., the application saves some representation of the area on a VR hand and when that area collides w/ something it automatically triggers and event with the interaction's information content

Rather than giving each individual lead a default polarity, allow leads to have default polarities per mapped lead set the lead is in. This allows different lead sets to use the same lead differently without one always having to know to override the default polarity value.