Or simply make an adornment with $InstrumentType.contains("Optical") | $InstrumentType.contains("Radar")
. I say this because I whilst I get the intent, I’ve a sense this scales badly, The issue isn’t what I as a user intend/imagine while happen when I actually use the tool (and as so often, not quite as I imagined I did).
Re the Tinderbox video, I assume you refer to c.7:35 and the adornment grid. The reason $Venue and $Slot values change is due to the adornment’s OnAdd action. A note moved on top on N overlapping adornments will receive the OnAdd of all of those atop which it sit (or partially sits). What follows isn’t an argument for/against, but simply an attempt to explain the status quo (as at v8.2.2).
Uniquely to map view an item is inside an adornment atop which it sits. Consider this map:
and this agent query:
inside("AAA") & inside("BBB") & inside("CCC")
…which, for the above map, matches ‘note 2’.
So, why not the same with smart adornments? As it is, a note can only match one smart adornment; I’m not sure if it is the uppermost (if overlapping). Any note matching the smart adornment’s query is moved atop that adornment. Any note not matching the adornment query is moved off that adornment onto (an unadorned) part of the map, ideally so as not to overlap another note.
Note that an accidental overlap might otherwise trigger an OnAdd action, or a nesting or composite effect. Queries and actions (rules, etc.) fire in outline (i.e. $OutlineOrder) sequence. Thus, whilst on a heavily taxed map you might see a note meeting several smart adornment’s queries bounce around the map, it’s more likely you see the outcome of the end of the agent cycle - i.e. the notes are arranged as per the last query evaluated.
The outcome is that at present a note can’t be placed automatically atop more than one smart adornment. also, given the above, re-tooling to ‘just’ make such an outcome possible is probably a little more complex than presumed, as the map would have to detect all overlaps, generate the merged queries etc. and factor that into the agent cycle.
All of which is not to say the asked for behaviour may/can not happen, that’s up to the developer. I’m just explaining why it may not be a simple/quick request to meet.