Those are some great questions!
Your analysis is basically correct. There are a few related tickets like #3827 as well that show other issues with the .trigger() design peeking through. I think the general team consensus is that inline handlers are both bad practice and a pain in our butts due to issues like this.
I suspect the reason this may not be reported very often is that the most common way for people to use inline handlers is to prevent the default action, which means they never see the double triggering.
If we're going to fix this and continue supporting inline handlers, we have to run them in the trigger loop up front so they can stop propagation and prevent default. In that case we'd need to figure out some way to remove/restore all the inline handlers just like we do for the target -- really messy for something we don't even want people to do.
Either that or we have to eliminate that trigger loop *entirely* for native events (still need it for custom events) and have the browser do the propagation. You're basically proposing that with the evt.target[event.type] test. That brings issues like #3827 into play, which would be a major breaking change.
As for capture behavior, jQuery doesn't support it via the external API. It's used in a couple of places for special events (see focusin and focusout).
