The termary operator ?: should be able to coexist. The way I was setting this up, the identifiers required that the ? was a leading, or trailing character, and I can put in an exception for STATEMENT ? EXPRESSION : EXPRESSION, or IDENTIFIER ASSIGN STATEMENT ? EXPRESSION;, or I believe that I can. This, and some of the other things to do with tokens, will come down to experimentation. If what I do works, I'll keep it. If not, I'll cut it, and cut my losses.
You'd also have to do extra work to exclude ? itself as an identifier and require spaces around it, which would be more arbitrary differences from everything else. Otherwise, you run into unparseable cases like
int x=foo??bar:baz;
Again, I don't expect it will ever be implemented anyway. DarkDragon considered it more trouble than it was worth, and I'm inclined to agree. Still, I'd rather keep the option than give it up for a cosmetic feature.

In these cases, I look at is a more of a kwhy notk situation. Repeat is just a shorthand for loop, and thus a shorter way of doing that. I've never seen it used in a script, though that doesn't make it impossible. In any case, our decision on this is that there may be small ZScript changes that require updating a minority of scripts, so unless we did something with sweeping impact--which is in the alloeed scope of 2.65 under our definition--it can stand.
I generally don't like the idea of throwing in every random thing one or two people want. Not a good work-to-benefit ratio, though it's probably not a big issue in this case. Beyond that, my only real objection is that we have a mostly amateur scripting community, and many users struggle with basic aspects of scripting as it is. Adding new ways of doing things creates more stuff to learn and remember, and it will make for a more difficult transition to AngelScript when the time comes.

Please explain, and give further details on what this is supposed to mean.
The sprite_list class has been rewritten and now assigns UIDs a bit differently. Manhandla heads and Patra orbiters will be numbered differently (they haven't been updated yet, so I don't know exactly how). Weapons created by a breath firing type are numbered differently. There may be more differences I'm not aware of.

Which in turn, is one of the problems with making ZScript functions, and vars that can actually affect the game, without being hellishly buggy.
Doesn't matter. The more stuff that's directly exposed to ZScript, the more we can never fix or improve. Making more problems permanently unfixable is the last thing I want to do.

Probably both, with incremental shifts towards full compatibility. Not as if there isn't already an arms' length list of inconsistent behaviour in ZScript, such as NULL values.
It's just too problematic. Quest rules were't made to be changed mid-game. I can't imagine how many bugs would result from it, beyond some of them simply not doing anything at all. Also, it'd make it harder to replace quest rules with superior options later on.
Quest rules don't make for a good scripting interface, anyway. If you put some rules one might reasonably want to change behind meaningful interfaces (e.g. Link->DiagonalMovement, Game->ContinueHealth), that should be okay. Even if the ZASM it compiles to is just SETQUESTRULE, that's less of an issue.

The point of this one, is to make it possible to do TraceS() without using a pointer to an existing string: TraceStr("This is what we're doing" ). Of course, how to store that string is another matter, but doing anything with char isn't happening soon.
Do you mean that you want to store the string as text in the quest separately from scripts and the actual function argument would just be an index? And this would be denoted only by the function used? That's a thing you could do, I guess, but it seems a lot harder than just loading the string into a temporary variable in a way that would work with any function.

What is the specific memory footprint for a single index? When I do the math here, I'm coming up with a different value? (131072 Bytes).
136 screens per map, 248 additional elements per screen.

It would still be nice to pop these up a bit, perhaps make it a size of 20, and make all the class->Misc[] arrays a size of 32. How bad is memory (RAM) handling for those? Probably the same issue, only it is based on object count.
They're fixed for each instance, yes. But those are dynamically allocated and not saved, so it's less of an issue

Are the old (non-public) ZC dev boards from 2.11/2.5 still archived? It would be extremely useful to be able to read them, to find out what has been tried, and know the pitfalls. I only know that the intent was to be able to set/get any value.
There doesn't appear to have been any discussion about it. Joe123 dealt with it on his own, as far as I can see.

I'll need to look at how icons are drawn, but if you only allow a single 8-bit icon, or four 4-bit, it could work.
Not in the quest, on the loading screen. You'd potentially need three full palettes along with the colors for the screen itself.

Why do the unsigned values roll at 32768? Is there any valid reason not to change them to the fixed type? Hell, I'd like to make signed fixed counters available.
They don't, as far as I'm aware. Can you give me a specific example?