World: r3wp

Words in R3 preserve the case they are typed in, but are considered 
equivalent on a case-insensitive basis.

...but that is the case of R2 words too

(the variants having different case are "automatic aliases", as I 
call them)

R2 words preserve the case they are *first* typed in, not the case 
they are  in every time.

I would need to see an example where it differs

I noticed the difference before, but am not able to replicate it 
now :(

nevermind, we will "rediscover" it :-D

In any case, for R3 line 502:
            if strict-not-equal? mold :a mold :b [return false]
should probably be this:
            if not-equal? mold :a mold :b [return false]

well, that is "in transition" still

Probably for R2 as well, if your statement about R2 case-preserving 
is true.

depends on the level of strictness we want to achieve for the said 
EQUAL-STATE? function...

Unless you want
>> equal-state? [A] [a]
== false

yes, that is what I achieved, as it looks

(lots of possibilities, and it was written long ago)

You do topological comparison here, not  marking.

yes, I am actually unable to do marking in Rebol

but, if you want a model, I can write one

do you know how many bits can I use for marking?

(or is it just one bit? - in that case it indeed is a problem)

Well, my point was that marking isn't enough here, and that this 
kind of comparison (the kind in equal-state?) is needed.

so, the question is, how many marking bits are available

Only Carl has that answer. Still reading...

You would have to do something similar to a simplified EQUAL-STATE? 
even in a C version. There will never be enough bits for marking 
because every concurrent instance of your comparison would need its 
own set. Having thread-local done lists would work though.

concurrent instance of your comparison
 -> "concurrently running instance of your comparison function"

concurrently running instance of EQUAL? - yes, understood, that would 
be impossible, but such a thing can be made "atomic/protected", can't 
it?

No.

why? RECYCLE and MOLD will be protected, won't they?

You can make GC single-instance, but not MOLD or EQUAL?. MOLD and 
EQUAL? will be done too often to lock.

too often to lock - I would say, that RECYCLE is more likely to be 
"encountered" than MOLD or EQUAL?

Unlikely - RECYCLE isn't FREE. The whole point to GC is that it isn't 
done that often.

yes, but it takes time: the "probability of encountering" is proportional 
to running time as well as to call frequency

OK, EQUAL-STATE? is too strict in another way: It also considers 
values that precede the series references. I'm going to figure out 
if it will still work if changed to use the level of equivalence 
expected from EQUAL?. Note:
>> equal? next [a a] next [b a]
== true
>> equal? next [a a] next 'b/a
== false
Not sure about that last one - will it be true in R3?

yes, re strictness, it will probably be found too strict in a number 
of ways

What about equal? [a b] 'a/b ?

(it was certainly not a prototype of any specific member of the current 
equality coparison hierarchy)

Are we doing equivalence within any-block! or limiting it to within 
any-path! ?

re last question: supposedly True

(ie. I would take the any-block variant)

but, you may propose a different alternative, if you don't like it 
for some reason

One alternative is equality within any-path!, within any-word! and 
within any-string!, but not within any-block!.

yes, the only difference is, that I considered any-block! to be the 
counterpart of any-string!, but that is just me

Another alternative (the current one) is equality within any-word! 
and any-string, but not within any-block! or any-path!.

I think, that currently the equality within any-string isn't imlemented

sorry for the typos

I consider any-block! and any-string! to correspond as well, but 
the question  is whether EQUAL? should do the same.

You are right about the equality of any-string! - not implemented 
yet.

yes, this needs to be decided specifically for the purpose of equality 
comparison

Remember, EQUAL? is the simplee default for people who don't want 
to worry about things. We have more strictness later down the line, 
buut a little strictness in EQUAL? would help newbies in some cases.

a little strictness in EQUAL? - do you mean, that newbies may be 
more comfortable with finer (stricter) or with coarser (less strict) 
version of EQUAL? in this case?

Yeah. It's hard for me to judge, but equivalence within any-block! 
seems confusing to newbies. However, equivalence within any-path! 
seems to be similar to equivalence within any-word!, so we might 
want to implement it.