Do you think that a line-by-line translation will be more readable than the I6 original?
Not as readable as a rewrite of course, but I think almost any function written in I7 is more readable than its I6 counterpart.
Looking at this, I see mixed improvements. "The parser's current word" is way better than "wn". "Do scope action and recurse on ... excluding ... under ..." is better than "DoScopeActionAndRecurse(..., ..., ...)", but only by the prepositions. Then you have a lot of lines that are essentially adding spaces and "the" here and there.
I had a good name for wn only because I already knew exactly what it was from my previous exposure to the code. The phrase and match_from I have less of an idea, hence the too-literal names. Since the I6 names are preserved for variables via "translates into I6 as" and to-phrase naming, I can completely rename their I7 selves like I did with wn. It's just I need to understand the code better before I can pick better names. You should have seen what I had before I hit upon those particular prepositions. Ugh!
The overall logic is exactly the same, which is to say occult in the extreme. (I see you translated the line "wn = match_from", in PlaceInScope. A couple of days I mentioned that particular line, as the immediate cause in the infinite-loop-scope-bug thread. I said I had no idea what it's doing there. I still don't. Do you? Anybody?)
I have a philosophy that if working code is quick and relatively bullet-proof, but its logic looks convoluted, sometimes it's just a question of what you're naming things. Sometimes the name of a variable is a poor match for the concept that it eventually ended up standing for. Since this project allows me to name many of the I7 constructs however I wish (parameters excluded), it's possible we find that the parser isn't as convoluted as it seems. It might even be elegant but we can't see it.
It's also possible to highlight certain patterns in the code, such as a long string of if-statements, which look like they'd be happy as a rulebook. The scoring especially. This can be brought out with I7 comments even if I can't express it directly code-wise. The line you bring up in particular I've seen multiple times, and the word "reset" comes to mind with it. I believe it's a safety mechanism in case other GPRs didn't reset wn like they're supposed to, or an off-by-one error happened. (Or maybe, since many matching routines only work on wn, it's using up wn to use one of those functions. If parsing is done, wn can be trashed.)
When constructing the Custom Library Messages extension, I slipped in the comment [reset to] in a now...is... assignment so I could tell when an assignment was meaningful or not. The same can apply here.
I realize that you've chosen a (sanely) limited goal here; the alternative is "write a new parser in pure I7." (I'm not touching that either, believe me.) I'm wondering what the specific benefits will be. ("Let's find out" is a perfectly good answer.)
I don't think a brand new I7 parser would gain much traction for the same reason that Glulx didn't immediately obsolete the Z-machine. So at the very least this project could be a stepping stone toward a better day: more people could join in with sensible opinions on the parser due to better readability, increasing pressure to standardize things like improved disambiguation, transparent scoring, etc. Besides, not everyone speaks I6, and that alone is a hurdle.
So I think there isn't much in the way of real technical benefits despite being a technical challenge. But I think the "soft" benefits of bringing in more community eyes are definitely worth it.
And I'll try to comment more.