The benefit of using an Attachment trait, is that Vassal does not have to query every single piece on the map. Indead, it only needs to query the attached or attached to piece(s).
Actually not a very good suggestion. This will query all pieces on the map, which potentially can be a great deal, and will be relatively slow.
If your leader counter is indeed a Mat - and the units are Mat Cargo - then addressing the carried units with selection criteria
{CurrentMatID == $MatID$}
will be more efficent. If the carried units need to address the carrier (the mat), then the selection would be
{MatID == $CurrentMatID$}
Mat and Mat Cargo traits are - however - really only useful if the leader counter does indeed carry around other counters, and these counters may change their leader - or mat. You should of course use Mat based sum and count functions.
If carried counters are only ever associated with a single specific leader counter, then the Attachment trait is more suitable. You should of course use Attachment based sum and count functions.
“aware” is a funny adjective to use about a piece of mechanics that guesses most of the time 
Do you mean Marker and Dynamic Property - then no. The value stored by a Marker is by definition a constant. The same goes for the initial value of Dynamic Property.
What you can do is provide a command for Dynamic Property - say initLeader - which will set the property to its initial calculated value. You can then trigger that command by a Startup GKC.
Take a look at Tools for module developers which has a bunch of links to tools that are useful for module developers - including Script to make common operations on piece images
Yours,
Christian