>My understanding of this matter was/is that this is transitional code and that the only reason for the old parser to be still present, is to be able to quickly switch to the new one. Once the new one delivers the same results and provides a superset of the old one, the old one is going to be removed, right?

That is right.

>that would clearly be overkill for a temporary feature, imho

I guess this is where we disagree. On one hand it is certainly easy to agree with you that changes proposed in this PR should be removed quite quickly, and that code cleanliness++ should therefor not matter very much. But my general answer to that is:

1. Unfortunately temporary hacks meant for imminent death tend to live quite long; sometimes they even become permanent. Based on that argument one should be extremely vary to introduce hacky code which one does not plan to live.

2. For a small change it often does not take significantly longer to do it nicely than do it hacky - just do it nicely; and of course then you'll meet a pedant like me who is willing to waste lots of time *writing about it*.

> that said, if you really, really, really insist on adding a runtime parameter, I'll do so...

I don't really really insist on any thing; but my point is that if you introduced a run time parameter from the outset it would have taken an additional five minutes - all in all that would have been a good investment!?

If possible I would *like* the statements to be assembled in only two blocks, one for new parser and one for old - and I do insist the PR is green before I push the button!