Actually, during my research I've found out that the problem is in the paint() method of the Marker class.

At the very last moment of the jump, IJ decides that it's a nice time to repaint all the markers and invokes paint(). Meanwhile, the AceJump livecycle is already completed and the variables are already reset. That means that Tagger.regex is set to false and the if statement in paint that executed all the time true branch now executes false branch which draws green marks.
So, my initial fix was to store Tagger.regex variable in the constructor and use it as a local property. However, with this approach, a part of the text is greyed out after the jump because during the very last execution of paint the line with composite = getInstance(SRC_OVER, 0.40.toFloat()) is called as well. I was not able to find a fix for the last problem, so I've set searchWidth to 0 in case of regex search, what 1) is technically correct 2) fixes the problem with green lights.

Perhaps the solution where the second branch is not executed at the end would be more correct.

Hi Alex, this is good work, thanks for investigating. The regex case should have been handled on a separate code path to begin with, but it follows the same path as text search for historical reasons. Since regex search should not accept subsequent search characters, I believe there are a few lingering bugs. Instead of cluttering the search path with control flow for regex, this case should probably take a different path since there is no notion of searchWidth, tag solving, etc.

Indeed, you are right -- there is something fishy going on with composite = getInstance(SRC_OVER, 0.40.toFloat()). I believe if you debug the whole rendering loop, paintMe get called more than is absolutely necessary (the whitish pane during regex search is evidence of it). It is in fact a bug, but we pretend it is a feature. It would be nice to isolate what is the problem exactly.

edit: Re: "At the very last moment of the jump, IJ decides that it's a nice time to repaint all the markers and invokes paint()" Interesting, I was unaware of this.

In general, Marker is a mess and should be completely gutted and refactored. I was looking into replacing Marker with a single CustomHighlightRenderer, which would work, but unfortunately gets painted underneath editor text, so in order to paint tags above text we need a Graphics2D. Perhaps we could investigate if there is another IntelliJ Platform UI component that would do the job and match the platform's look and feel.