Historically searching for empty series in a series would fail:
rebol2>> find "abc" ""
== none
This seems inconsistent with what it would seem you would want, e.g. in PARSE when a string is empty:
>> parse "abc" ["" "abc"]
== "abc"
Of course, when PARSE had the "must make progress rule" it wouldn't work. But the fact that FIND didn't support it provided a reason why it wouldn't work even without that rule in place!
Conceptually Why You Should Always FIND an Empty Series
You can think of a string as being any number of empty strings glued together...
>> unspaced ["" "" "" "a" "" "" "b" "" "" "" "c" "" ""]
== "abc"
So it doesn't seem that strange to say that you can "find" an empty string at any point you wish to look.
(The same reasoning applies to finding empty blocks in blocks, etc.)
Feature-Wise Why You Should Always FIND an Empty Series
It seems that the ability to uniquely express the intent of VOID vs. empty string gives FIND the ability to discern the two, offering a means of opting out (never find the target, always return null) -and- a means of opting in (always find the target, returning original series):
>> find "abc" void
; null
>> find "abc" ""
== "abc"
(At time of writing, VOID rules are treated as no-ops in PARSE...but synthesize a null.)
This Changes PARSE and FIND for the Better...
Red doesn't embrace the FIND feature:
red>> find "abc" ""
== none
But they do accept that "" is a match in PARSE:
red>> parse "abc" ["" "abc"]
== true
Which seems inconsistent. Either there's an empty string you can match at the head of "abc", or there isn't!
This is another one of the benefits to implementing PARSE in usermode, and forming a consistent model across the routines.