I haven't worked with Shadow DOM myself, but I would say you are probably correct about needing to create custom events that you then listen for with Launch in order to trigger tracking.
As for Activity Map... You can't even "extend" activity map to track non-standard navigation items... by which I mean, I can track things like anchors and buttons, as these are "standard" navigation (buttons require a little code manipulation to work)... but if your developers take a div or span and apply JS to it to make clicks on the element navigate to another page, I've never successfully made that work....
However, you could create your own replication Activity Map.. basically, add some data to a session storage value when an element is clicked; then on the next page, read the values into your own props or eVars (hit level); then delete the session variables.
This will not appear in the Activity Map plugin... but you can use it in Workspace.... to be honest, I only use Activity Map data in Workspace.. I haven't used the overlay extension in over 8(?) years....
So if you want to use the overlay, I think you are out of luck.. if you are only planning on using this as pure data, then a custom solution should work.
I also suspect that most heatmap products out there will have a lot of the same issues... with the elements not properly registering...
Now, just my two cents... Shadow DOM sounds like an absolute pain to work with, but more than that, I would be concerned that any site coded in this fashion wouldn't comply with accessibility standards....I would also worry about SEO.
Is there a compelling reason for this choice? If this is a new build in dev, your team may want to do a feasibility study to make sure that you aren't developing something that will kill the SEO of your site, and depending on your local laws, have you sued for having a site that can't be used by screen readers. Maybe this has been addressed... I don't know... but it sounds risky and that it's making everything more difficult....
