separating core software issues from others is sensible, but non-core features can be essential. for example, the C programming language would not be at the foundation of so many things if it didn’t have a standard library. thus, core specifications reconcile fundamentals while extensions supply invaluable high-level features.
adopting a core-first mindset, i reviewed the 0.30 Milestone issues to estimate the 1.0 release date. unfortunately, my notes quickly became cryptic. in situations like this, i try to categorize the issues i discover. this style of analysis induces me to structure my notes, so table usage is almost inevitable.
at the risk of making this reply far too long, Markdown tables seem even more useful in real life as it were. i use them to record test results produced by various healthcare providers. most recently, i made a table to reconcile two compilations of 78 rpm recordings with an American Music discography. i never generate HTML from these Markdown documents.
creating/maintaining a tabular summary might facilitate monitoring the status of Milestone issues. furthermore, standardizing table syntax might be easier than finalizing the 1.0 core specification? after all, a specification can add value by formalizing common usage, cf. your favorite dictionary. Le mieux est l’ennemi du bien!