Yes, but KM should do nothing, but wait until one of the apps listed in the macro is the front app. And that can only be the case when the AltTab window is closed.
Did you replace ⌘tab with ⌘9 in the AltTab settings?
And important is "any of the following are true".
Right, but you're still triggering the macro potentially many times over, which isn't ideal. 
Yes. Part of the issue, as mentioned, is that AltTab doesn't seem to be recognizing that the keyboard shortcut has been released, so it doesn't bring the selected window into focus.
Okay, that's weird. Everything works for me. 
Nice idea, @Frankb, but unfortunately this solution is not reliable on my machine, sometimes it works, sometimes it bugs - especially on quick presses - where I have a pane of alt-tab windows stucked at open state, but if I press and hold alt, then seems to be ok, I do get all other windows of an app to the front as well (and then KM engine gets high CPU use, maybe it's stuck in some loop)
Thank you @esv. The idea may be nice, but my execution is terrible.
The question remains, why does it work for me but not for others?
Could this have something to do with the settings in AltTab?
Have you tried putting a pause here and there? Surprisingly, it only works for me when I have this pause of 0.5 sec. It took me a while to figure that out.
yes, added a pause after the first step, increased the pause to 1 sec and a couple of other combos (but nothing exhaustive)
have you tried a sequence of immediate switches? When you tap once and quickly release, like when you're trying to switch between two apps below the apparition delay threshold? Or do that twice to go back and forth, something bugs in this area, have also encountered a similar issue when was trying to use Karabiner to trigger Alt-tab for some tricks, it's just unfortunately not very composable 
It all works perfectly, whether I do it fast or slow. First the selected window of an app appears and with a slight delay all the others. But when I do this quickly, the AltTab window does not appear at all. But it still works.
Have you tried to change the shortcut ⌘9?
Yes, that's the one I've tried precisely because I didn't want to get into more same-shortcut bugs
yeah, this part always works, once KM takes over and sees the window, the next step is done fine
The main bug is when AltTab doesn't get release event on fast switches, so its window always appears even if I release before apparition delay (and I've disabled Karabiner/BTT to try to avoid interference)
This is slightly absurd. It works for me, even though I don't need this feature, and for you it's the other way around. 
Is there no way to force AltTab to execute the release event? Are you on v 6.61.0?
indeed
Version 6.61.0
But I think I've found an easier way to bug KM:
so it doesn't seem like AltTab misses the release event, but rather KM not producing them properly (or maybe there should be a more advanced input simulation rule)
By the way, for the folks in this thread who would like to see AltTab add this option natively, feel free to chime in here on Discord, which the developer will see...
Hi, does this do what you want?
Looks too simple to me reading this lenthy thread, but it seems to do what you describe...? If you don't want this to happen as soon as you click on any other app's window, maybe this variation might help:
I did not try AltTab actually, so let me know if I understood you wrong!
It's an interesting idea! I worry that it would trigger bringing windows to the front in instances where this isn't desired, but I think it's worth a shot. Thanks, @Waldbaer.
Yes, this might become a problem. If the "If key 'tab' down" solution does not work, you might try to use another macro (2) triggering whenever "AltTab activates" (comes in front) and activates the simple Macro I suggested above (1) (which would be deactivated normally). You could activate it for a period of time or build a third Macro deactivating the first after triggered by "AltTab deactivates" (maybe after a short wait to make sure it fired). Good luck!
Nope, but this gave me an inspiration to just ignore AltTab completely and I think the example below works with an extra condition and a cancellation timeout:
No more stuck windows! And conceptually this seems a bit cleaner as it doesn't try to control other apps?
(Haven't tested this much yet, had high CPU , but that might've been a holdover from the previous macro or maybe sleepers not being cancelled?)
Looks good! You have combined elements from different ideas.
But it's unsatisfying to have to list all apps. If you want, try a menu condition.
It is, is there an "any app" 
entry? Or at least a way to set some /Applications path prefix? Or just batch-select?
I think you could write a script to edit the XMl to enumerate all apps and append dicts like ↓, but that's still tedious and needs updates
<dict>
<key>Application</key>
<dict>
<key>BundleIdentifier</key>
<string>com.apple.TextEdit</string>
<key>Name</key>
<string>TextEdit</string>
<key>NewFile</key>
<string>/System/Applications/TextEdit.app</string>
</dict>
<key>ApplicationConditionType</key>
<string>Active</string>
<key>ConditionType</key>
<string>Application</string>
</dict>
Another idea: is it possible to detect when AltTab's window switcher window appears/disappears? I tried Window conditions, but those don't seem to catch the switcher (I guess it's a special kind of window?)
The menu condition is unfortunately not reliable (does KM try to parse all the menu items? as that might be slow with many items)
It's not a solution with KM, but John Siracusa made an app specifically for this. It's called Front and Center. It enables you to switch the window behaviour on app activation.
App Store: Front and Center im Mac App Store