There is no perfect solution. "Matching the indent level" of a mixture of blanks and tabs relies on knowing where the tab-stops are. We could add a bunch more options to support the notion of tab-stops, as perltidy does, but that doesn't protect you from an inadvertent (or deliberate) leading space that turns a line into a verbatim line when that wasn't the intent. For what I have been trying to do, verbatim lines are relatively uncommon, so I don't mind going a little out of my way to make other stuff foolproof, if that makes verbatim lines a bit clumsier.

Given the response to this thread that could most charitably be described as "tepid", I have what I need, and I'm pleased that I'm not reinventing some existing wheel. If you have a preference for an alternative that works better for you, go for it. I'm not eager to push the idea much further.

How does having the desired indent of the code fall after =v make that issue go away? It might look lined up under the current circumstances but will be all jumbled for someone else.

I suppose you are saying that your way will at least ascribe all the lines to a verbatim paragraph, even though they may be indented wrong in the final presentation, as preferable to not identifying them properly at all.

OK, how about after the =code initiates things, it will take all lines until another directive or zero-leading whitespace. It won't worry if the indention matches the initial line, but will clamp at zero after it removes the expected amount.