With the minor advantage of avoiding the overhead of the regex subsystem. It's great for many problems, esp. complex ones, but as a very generalized solution many simpler problems benefit from simpler parsing methods.
This also works across line breaks, through presumably an engine-level enhancement could handle that as well.
It would be interesting to have both so we can gauge performance improvements in LCB over multiple iterations. I realize it's too early to expect optimization just yet, but the language was designed for, among other things, performance opportunities not possible with LCS. At the moment we have few (none?) examples allowing performance comparison.That’s why I think implementing in the engine wouldn’t be that monumental of an effort. I think we just need to define the LCS syntax first. I’m also wondering if I could do it in LCB (access to composite types being the question).