The specific thing with Rosen's and Eskin's code that screws things up for me: they insist that all gracenotes are implicitly slurred, and if you write them explicitly slurred, it screws up the whole display of the tune with slurs going everywhere. For my transcriptions, I write what I see in the original: people often mix slurred and unslurred gracenotes. I'm not making that decision: whoever wrote that tune down 200 years ago did. The distinction between the two ways of writing gracenotes may or may not be significant in the context - but you don't want a software implementor setting their own rules to rule out constructs that have always been acceptable in standard music notation and which you could count on an ABC implementation respecting in every platform previously.

I can't change any of the ABC I've posted to the web - not only can I not update my own site now, my ABC has been copied to many other places (including Mudcat) where I've never had way to change it.   And I'm not the only one to do this. The time I have put in to doing ABC transcriptions accurately is FAR greater than the time Eskin and Rosen have put into their implementations. Every other implementor I've been in contact with (almost all of them) has been willing to fix bugs when their system fails on something in the existing ABC corpus. This one CAN'T be hard to fix - just don't invoke the slur generating code by default when there's a gracenote in the source.

You don't get compiler implementors deciding to change operator precedence for code written before they were born. You don't get spellchecker implementors deciding to relegislate the rules of English. You accept the way the users write and the way the standards have it.