No, only when it's transferred to another calculator (it's checked at the receiving end, that is.)

I think they have, but I don't expect they'll ever take those bits of code out.  And even if they did - even if they released new OSes tomorrow that did away with all the old protection mechanisms - I'd still say it's worthwhile to remain compatible with the older OSes.  I mean, personally, I'm still using 2.30 on my 84+, and given the state of the newer OSes, I don't plan on upgrading that in the forseeable future.  I think both my 83+es are running 1.19 now, but I kept 1.14 for a very long time, for the sake of program compatibility.  I'm sure I'm not the only one.

Okee, I think I'll give it a try. Meanwhile, I just had a brilliant idea with an interrupt, if only I could manage it in my head. It will be my first interrupt \(^_^)/

Sounds scary.   I'm still amazed at how you can program the way you do.  Good luck!

Well, first off, for normal system B_CALLs, between 4000 and 7FFF, the B_CALL handler first looks on page 1B (or 3B or 7B, depending on the model), where there's a table of all the system routine addresses and page numbers.  So for instance, if you do a B_CALL GetKey (4972h), it looks at the 3 bytes stored at address 4972 on page 1B - in OS 1.19, that's 8B 49 06, i.e., address 498B on page 6.  The OS then pushes your original page number on the stack, as well as the address of a handler routine (on page zero).  It then loads page 6 in the 4000h bank and jumps to 498B.  When the GetKey routine returns, it returns to the handler, which pops the original page number off the stack, restores that value to port 6, and returns to your program.

Boot B_CALLs are provided by the boot code, not the OS.  They work exactly the same way, except that you use an "address" between 8000 and BFFF; the B_CALL handler subtracts 4000h from that value, then looks up the address to call on page 1F (instead of 1B.)

And finally we have application B_CALLs, like I mentioned above.  In this case, you use an "address" between 0000 and 3FFF; the B_CALL handler adds 4000h to that value, and looks up the address to call on the first ("base") page of whatever application is currently loaded in port 6.  In this case, the page number listed in the table is relative to that base page (so if your app is stored on pages 15 and 14, a value of 00 in the table corresponds to page 15, and 01 corresponds to page 14.)

(B_JUMP does the same thing as B_CALL, except that it doesn't save the original page number or push the extra handler on the stack.  You almost never want to B_JUMP to a system routine, but you may sometimes want to B_JUMP to routines within your app.)

So if I have an app, could I read in the page I'm running on, then swap it into bank 2 and jump to bank 2, where I then swap in the RAM?  Probably tough to pull off in Axe, but I have a few ideas.

That would work in assembly language - as you say, it might be tricky in Axe - but you'd want to be sure interrupts are disabled.  Like I said before, the OS doesn't like it if you change port 7, and that includes the system interrupt service routine.  And remember that stuff like the screen buffers and A-Z variables are all stored in that area as well.

Another option, with the same caveats, would be to simply leave your app mapped in the 4000-7FFF slot, and temporarily map whichever RAM page you're interested in in the 8000-BFFF slot.

Yes, it's okay, and thank you
That gives me C000 and up as free RAM, correct?

No, that's port 6, which controls the 4000-7FFF area.  And if you want to use the area from 4000h to 4080h, you should also add a B_CALL FillBasePageTable (that's EF1150) to clean up when you're done.

No, of course it doesn't.  We were talking about what to do if you get into the situation where you cannot install an OS.  Which implies that your OS has been partially or completely erased somehow.