I found out if you execute poke(0x5f55,any valid number not 0x60) on the console, the screen gets remapped to the address but the editor never resets it back once the code is done executing, visually breaking the editor in the process, up until you blindly write the function poke(0x5f55,0x60) to go back to the original screen.

I'm not sure this is a bug technically. If you tell PICO-8 to draw to upper memory instead of the screen, that's what it does. You'd get a similarly unusable environment if you call pal({0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0},1) from the command line.

Code executed on the command line persists for the current execution. You should need to undo it yourself or reboot to revert.

@kozm0naut ,you forgot the ,1 at the end of your pal statement example. When things get messy like that, pressing CTRL+R resets things to a cleaner state.
While I 100% agree that it is the correct behavior from the command line, as you WANT to be able to test things from it, I'd personally think that the editor should be shielded from pokes... And yet I like to be able to change the palette to the one chosen for the game, so...

Personally, the fact that you can corrupt the entire environment by fooling around in memory is one of my favorite things about using a fantasy console instead of a real machine. It has taught me that RAM isn't a magic untouchable box, it obeys very logical rules, and while we need to be careful interacting with it directly, it is possible to do safely and it can be an extremely powerful tool.

As a side note, I highly recommend Memsplore and the accompanying YouTube video by @Krystman for anyone looking to understand more about PICO-8's memory.

I feel like if it was intended then it wouldn't be possible to press escape and the screen to still change, even though the screen memory is in another place. Also the image should display the screen contents at 0x8000, not 0x6000, right? I don't know, if it was a feature then it should work fully not halfway.

I was curious about that too, especially that it still draws the menu bars in place, but my assumption is that these aren't done with draw operations (which are specifically what is impacted by poking 0x5f55 afaik) but by setting those blocks of memory in the 0x6000 block directly (they are contiguous after all). I don't know if there's a way to review the tools' code, but I'd be interested in taking a look if anyone knows how.

It would be nice though to have it actually use the other screen location instead of resetting the poke, so you can press CTR-R and pretty much take a snapshot of the editor where you can look it up later with some bits of code... though that starts becoming a problem if the user doesn't know that poke to 0x5f55 happened (since everything including the displayed image would be pointing at the himem screen, pretty much making it unnoticeable) so they would be corrupting their himem when they do a single console command every time

You could draw the contents of that memory area to screen by poking 0x5f54 with the same value and calling spr(0,0,0,16,16) (edit: though you would probably have to revert the poke to 0x5f55 prior to this draw)