First, a simple program:
[Main i j k l; @set_font 4 -> i; @set_font 1 -> j; @set_font 0 -> k; @set_font 1 -> l; print i, " ", j, " ", k, " ", l, "^"; ];
I tried this in 10 interpreters (including my own WIP) and I got literally 10 different results.
Of course, part of that difference is that interpreters might not support font 4. That leaves six that return 1 for the first call and still disagree on the rest. I think it’s obvious that, if the first call succeeded, the second should return 4. So, in an interpreter that supports fixed fonts, i should be 1 and j should be 4.
The real issue is @set_font 0. The standard (8.1.2) says that “font ID 0 means ‘the previous font’.” However, some interpreters treat @set_font 0 as a no-op and just return the current font. While useful, in that you can find out what the current font is, I can’t see how this is standard behavior. I would expect @set_font 0 to switch back to fixed, which was the previous font, and return 1. A number of interpreters return 0, indicating that font 0 is unavailable, but I suspect this can’t be right either, because they apparently had no problem setting font 4 (or 1, for that matter, which must be available).
Finally, the last call I would expect to return 4, since I expect @set_font 0 to have switched to font 4. At any rate I would not expect 0 to be returned, because font 1 must be available, and a couple of interpreters return 0 (probably because the 0 from @set_font was stored on the previous call).
The real burning question: should multiple calls to @set_font 0 alternate between the previous and current fonts, or should it simply return the current font over and over?