Rebol has two major areas of case-insensitivity by default. One is in binding, so variable naming and function names are handled case-insensitively. The other is in general treatment of data...so routines like FIND, etc.
Historically data case-insensitivity has applied to = / equal? as well. Ren-C plans to undo that particular choice, with the IS and ISN'T proposal. The "wordish" IS would fall under the case-insensitive operation of the "wordish" operations like FIND, while the "mathish" = would align with the stricter expectations that programmers would expect out of an equal sign.
I'm moving ahead with this for Beta/One...and have to say it's looking rather good so far. I think that I underestimated how easily we scan English phrases like method is 'script as infix and meaningful...it reads more comfortably than I expected. I even thought of a way to emphasize the case insensitivity when comparing to a literal: use mixed case for the thing on the right. So method is 'Script.
But doing the changes, I also realize how many instances were using = because it's prettier and easier to type than ==...when strict equality was actually what was intended (or would be preferred). It's chronic...and for instance, nearly 100% of the tests in the test suite which used an = meant to use ==...with the only exceptions being those few tests that were specifically designed to test lax equality.
But if I'm noticing how frequently one meant == when one had said =, what is the essential difference between:
[a b] = compose [a () b]
did find [[a b] [c d]] [a b]
If these were tests, both would prefer case sensitivity, wouldn't they?
This raises the spectre of the old "why case-insensitive at all?" debate
That debate has been opened, looked at, and closed several times already. It's no longer on the table.
Still, when a decision bucks the trend of basically every mainstream language in such a big way, there should probably be a coherent defense somewhere to point people to. So I collected my thoughts together here in a blog:
http://blog.hostilefork.com/making-the-case-for-caselessness/
As far as I know, that is the best single-document argument made to date on the topic. If you want to submit addendums or corrections, comment on the source on GitHub
So IS and ISN'T tweak a couple of operators, THAT'S IT
(...although I've mentioned it's not likely that <fOo> is "FoO" will be true. The type mismatch is a difference that goes beyond case.)
This is not a referendum on case insensitivity in the language. All this is doing is changing english-word operators to line up with the language's lax default, and lets symbols like = provide a stronger rule, as the exceptions since they are mathy.
I'm looking forward to seeing == die off in equality, and be used for other purposes in code. I've imagined it as a MarkDown-like construct, for doing conditional debug output. The number of = signs used could indicate the verbosity level at which the message might be printed, and it could be variadic to gather the arguments between marks, to feed into a PRINT statement.
== {Main Loop} ==
// ^-- e.g. prints if verbosity = 1
repeat n 100 [
=== {Process Item} n ===
// ^-- e.g. prints if verbosity = 2
...
]
I think it's going to be a great change.