Isn't that just because there's a wall in the top row, at either side of the screen?

Likely yes, the same way you can stand on the lower area if the platform is at the top (as per the first test) , I've not quite got my head around the quirks in the engine permitting this, the same as you can move/wrap around the edge of the screen and end up with half a sprite temporarily.

The check for a standonable platform underneath Willy is extending down past the secondary attribute buffer (#5C00-#5DFF) to the primary attribute buffer (#5E00-#5FFF), in the same way that the Fire cells at the top of the screen can kill Willy when he is immediately beneath them at the bottom of the screen.

In the previous files, the newly-created permanent water cells are printed at the top of the primary attribute buffer, and Willy can stand on them in the same way. The change to Water comes about because Willy alters the value of the attributes for those cells by imprinting his white INK onto them. The reason that doesn't happen in the last file I uploaded is because those cells - and all the Air cells - already have white INK. (Which also explains why there aren't any items in the cavern - they were there, but get automatically collected [like the one in JSW's Swimming Pool] in the first time-frame. And because there aren't any Water cells created to curtail Willy's fall, he plummets forever!*

*Except that he doesn't keep falling forever! Leave it running for a while, and eventually (after approximately sixteen descents of the whole cavern), Willy's airborne status indicator will be incremented to a value of #FF - signifying death!!

A minor variation, I did this before I saw your above reply just now. Mainly to see the effects of a bit of a gap around some of the edging as such. Variations of a theme I guess, although I moved the items to just be above and below the portal as well as spacing sensibly the climbing water cells a bit:

I was able to walk along under the Portal with a bif of care, grab the two items there then move to one side and jump reaching the upper plaforms, then it was just a case of falling straight down collecting the above Portal items on the way!

*Except that he doesn't keep falling forever! Leave it running for a while, and eventually (after approximately sixteen descents of the whole cavern), Willy's airborne status indicator will be incremented to a value of #FF - signifying death!!

I did notice that as it does eventually call the death routine, I suspected as the AirBourne indicator had reached its final value. I did note yesterday actually with one of the Fall variants at least even if you set the infinite falls via:

35809 , 255 / #8BE1, #FF

M.W will eventually die as he's gone too far. To be fair that poke is intended to prevent a cavern 'accident' not really a wrap around I suspect. There is at least one other poke for it as well, that one is from the Disassembly. The alternative one is:

35682 , 0 / #8B62 , #00

But that removes the INC A instruction to increase the AirBourne counter, you can easily tell if that one is applied as the fall sound is static rather than the regular decremental blips. That reminds me actually of the two erm choices for JSW for the same thing thinking about this:

JSW: 36578 , 16 / #8EE2 , #10 , Falling sound preserved!

JSW: 36477 , 1 / #8E7D , #01 , Falling sound ruined! , this one is the more common one that's been around a longer time iirc

I did notice that as it does eventually call the death routine, I suspected as the AirBourne indicator had reached its final value. I did note yesterday actually with one of the Fall variants at least even if you set the infinite falls via:

35809 , 255 / #8BE1, #FF

M.W will eventually die as he's gone too far. To be fair that poke is intended to prevent a cavern 'accident' not really a wrap around I suspect. There is at least one other poke for it as well, that one is from the Disassembly. The alternative one is:

That's a weird one that - the upshot is that it checks if the fall counter equals #FF, and if it does, then the fall counter is 'updated' with the same value that it already holds (#FF)!

35682 , 0 / #8B62 , #00

That one WILL allow him to fall forever (in the file which I created last night, where there is nothing to break his fall)!

But that removes the INC A instruction to increase the AirBourne counter, you can easily tell if that one is applied as the fall sound is static rather than the regular decremental blips. That reminds me actually of the two erm choices for JSW for the same thing thinking about this:

JSW: 36578 , 16 / #8EE2 , #10 , Falling sound preserved!

JSW: 36477 , 1 / #8E7D , #01 , Falling sound ruined! , this one is the more common one that's been around a longer time iirc

That's a weird one that - the upshot is that it checks if the fall counter equals #FF, and if it does, then the fall counter is 'updated' with the same value that it already holds (#FF)!

Potentially a new quirk/bug ? My leaning is towards a quirk with it though

That one WILL allow him to fall forever (in the file which I created last night, where there is nothing to break his fall)!

Yes!

I think that last POKE should be 36476, 1 / #8E7C, #01 ??

I'm not sure as the one I posted (36477) is the one that's been used for years, its still implanted in my head! I can see that would change the LD A , 12 to LD A , 1 (preserving the sound) however a quick test showed that Willy still died from a reasonable fall from the Bathroom ramp ?

EDIT... Replied to a PM with an .rzx regarding the last point, something slightly amiss is going on.

I did try an inverted cavern earlier this morning but the results were quite poor even after I'd inverted the guardians so they worked correctly (and looked half decent) upside down, I even tried with the platforms as \ / instead of / \ but it was not really any better so I did not keep the results.