The SPLICE! antiform could give us some pretty interesting options for avoiding the creation of series that we don't need.
Here's something that doesn't work today (because FIND hasn't implemented it), but it could be made to work:
>> part1: "an"
>> part2: "example"
>> pattern: spread reduce [part1 _ part2]
== \~["an" _ "example"]~\ ; antiform (splice!)
>> find "this is an example of what I mean" pattern
== "an example of what I mean"
Notice we didn't need to create the series "an example" to do this FIND; we could just use a small splice that sequenced the parts.
Of course, we did have to create the SPLICE...and with such short string components you'll be breaking even...if that.
But if the components were larger, this could make a difference.
I think the potential for this to be optimized suggests going ahead and allowing SPLICE! to be matched in FIND of strings and binaries, even if inefficiently by merging a temporary inside the FIND implementation.
This way, you can write your code in this style and one day it might suddenly get faster and use less memory when the internals handle it without merging.