Fixed it. See also:
Visual PARSE on the Web... has arrived!
Ideally we'd have tests to make sure these stay running, but...
The bug here was a consequence of an obscure code trick that isotopic ~true~ and ~false~ broke.
There is a function in %dungeon.reb called IN-BOUNDS that clips the passed in position to a boundary, but also returns true or false as to whether the position needed clipping.
This gave rise to a strange REDUCE, whose purpose was to work around the short-circuiting nature of ALL:
all-inside: did all reduce [
in-bounds start-pos [1 1] display.screen-size
in-bounds end-pos [1 1] display.screen-size
]
By doing a REDUCE step to produce a BLOCK! of two LOGIC! and running the ALL on that, there's no short circuiting of the calls to IN-BOUNDS.
You can't do this under the isotopic definition of ~true~ and ~false~, because isotopes can't be put in blocks. You'd need to META them:
let all-inside: did all reduce [
meta in-bounds start-pos [1 1] display.screen-size
meta in-bounds end-pos [1 1] display.screen-size
]
...
return all-inside
This would give you quasiform ~true~ and ~false~ in the REDUCE step, which would then evaluate to the isotopic forms during the evaluation with the ALL.
(If words like "isotopic" and "quasiform" seem alien, please read this: A Justification of Generalized Isotopes)
Anyway, rather than just make a puzzling piece of code more puzzling, I just simplified it:
let start-inside: in-bounds start-pos [1 1] display.screen-size
let end-inside: in-bounds end-pos [1 1] display.screen-size
...
return start-inside and end-inside
(I'll mention that there is consideration of a non-short-circuit ALL called EVERY which receives the product of each evaluation and succeeds only if all of the steps do. I haven't really used it, and it is potentially on the chopping block under its current formulation.)