I've been working on the frustrating question of how to make case-insensitive binding work without sacrificing the gain of space of a platform pointer per word cell.
It's rough and not pushed to master yet. But it's mixing with Virtual Binding:
>> abba: 304
>> obj: make object! [abba: 1020]
>> code: [ABBA 'Abba ''abbA '''aBBa ''''AbbA '''''aBba]
>> do in obj compose [map-each x (code) [get dequote x]]
== [1020 1020 1020 1020 1020 1020]
>> map-each x code [get dequote x]
== [304 304 304 304 304 304]
Strategy: Assume More Than 3 Casing Variations Uncommon
The design I've gone with is to assume that there aren't that many case variations of the same word in most situations. Maybe you have accept-headers, Accept-Headers and ACCEPT-HEADERS. But you won't go too far beyond that with ACcept-HEAdERS etc. If you do, then the words start to "cost more".
Some of this stuff gets pretty vague in terms of whether I'm playing by the "rules" or just twisting code into a pretzel.
I've oft-mentioned the "4 platform pointers per cell" baseline. That's pretty limited. Also limiting is that R3-Alpha tried to do essentially everything with arrays and linked lists... and this is a far cry from being able to easily pick from any of dozens of vetted data structures to suit your problem.
So what's going on here is that if you use a "sufficiently weird spelling", then your cell turns into the kind that points to another cell for its content. This is how QUOTED!s at the higher levels (4 quoting levels or more) work.
The ramifications are subtle and pervasive. A lot of code would assume it could just go and muck with parts of cells, but now that these expanded format cells can be shared you can impact cells you didn't mean to. If you want to tweak a WORD! cell so that it's a SET-WORD!, you have to worry about whether it's an unusual-spelling word...and if so, you need to make a copy of the shared cell to update its bit patterns. I've established ways to check some of this at compile-time, but it's kind of hacked together at the moment and needs tuning.
I'm suspecting that the average program would never need any of these cells (4 levels of quoting or 4 case-variations)...but that makes it all the more important to find ways to test it, by making the uncommon case common. Basically forcing all words to use the expanded format and seeing what breaks.
Object Keys Are Now Canon (Lowercase)
This applies to MAKE OBJECT!, and things like function arguments:
>> make object! [ABC: 10, Def: 20]
== make object! [
abc: 10
def: 20
]
>> func [ABC /Def] [print "Functions too."]
== #[action! [abc /def]]
I've written about how I believe this is the only sane answer to dealing with it ("Case Insensitivity vs. Case Preservation (can't have both)").