You are right, it’s not easy. But i see no alternative to make users less dependent on parser and md/cm spec maintainers. IMHO it’s a reason of huge deviations in markdown parsers - one day people begin to create “yet another parser for yet another markdown”, because old one can’t be extended. From another hand, i have some disagreements with jgm, but this doesn’t interfer markdown-it to follow commonmark spec. Because all conflicting cases are moved to plugins.
I’m interested in experience exchange with another authors, who decide to design parser with plugins. We did a lot of work in this direction, but existing state machine requires 1-2 more rework iterations to reach optimum.
Well, i can’t say i’m happy if you decide to move this way, but it’s your choice. Anyway, i advice to dig keywords:markdown-it-plugin - npm search. It has more complete info about what people really need (of cause it includes all popular extensions too).
Try to search in trackers of cmark, commonmark.js and markdown-it for sourcemap requests, and contact issues authors. AFAIK, the most demanded areas are syntax highlight & range selection for copy-paste in editors.