Of course, it's different for tools that aren't open, but. Using best-in-class tools rather than making new ones is usually just a reasonable choice to avoid fragmentation of effort/interest that's ultimately pretty harmful to any software ecosystem.
As an example.. any candidate for replacing jq needs to be either faster or easier. If it's only a faster implementation, why change the query language? If it's only a different query language but not faster, then why not transpile the new query language into one that works with the old engine? Doing both at the same time without sacrificing completeness/expressiveness in the query language may warrant fragmentation of effort/interest, but that's a very high bar I would think..
> If it's only a faster implementation, why change the query language?
Often enough, languages have weird accidental quirks of the implementation that resist fast alternative implementation. There are ways around this (and of course there's nearly always room to improve the original implementation without having to entirely redesign it), but sometimes it really is easier to just implement a different language.
As an example.. any candidate for replacing jq needs to be either faster or easier. If it's only a faster implementation, why change the query language? If it's only a different query language but not faster, then why not transpile the new query language into one that works with the old engine? Doing both at the same time without sacrificing completeness/expressiveness in the query language may warrant fragmentation of effort/interest, but that's a very high bar I would think..