Would it be possible to adopt some CSL-M extensions for standard CSL? I know some of those extensions might perhaps warrant extensive discussion, but I think there might be some fairly uncontroversial extensions, e.g. context tests (bibliography vs citation) or the extended testing logic. My impression is that these make styles easier to code an better to maintain. What speaks against adopting them in standard CSL given that these features are already there at least in citeproc-js? At least, such a change wouldn’t break anything in existing styles…
See my comment here about opting in to unstable features. I’m rewriting citeproc-js in Rust at the moment, and unifying CSL(-M) is a major goal.
That’s not quite right. There are currently 7 different citeprocs (6 if you don’t count citeproc-java because it’s a wrapper for citeproc-js) and at a minimum citeproc-ruby and citeproc-pandoc see significant use, so citeproc-js very much isn’t the only game in town.
I’m not generally opposed to this, but I remember there being some objections against the citation vs. bibliography testing (and I’d have to say it wouldn’t be high on my list in terms of the csl-m features I really want). Generally, our thinking is that we should get a very modest, terms-and-variables-only release out first, that will be trivial to implement for any citeproc. For CSL 2.0 (or whatever we’ll ned up calling it) we can then discuss more features. High on my list would be the improved in-text behavior that Zotero & Frank have been working on, more localization (things like and/ampersand and delimiter-precedes-last), and a number of csl-m features. Some of these will need discussion both about whether they’re needed and what’s the best form to implement them, so given past experience, I’d guess that’ll take some time.