My thinking was lean into lisp lists rather then the actual rendered format, so that instead of a text buffer (although you could always open up a text buffer that is the lisp list) you have a list that you can use normal elisp functions that is bindable to keys and highly customizable and your only really building fairly simple elisp machinery on top and you can just use an alist (though you could use a plist I think alist's work better for todos) to represent todo's and just use assoc and setf and friends to do your modifications.

Of course one might also want to actually build out todo nodes as CLOS style objects. Only caveat hear is that you would need to decide how the object should be serialized and deserialized and the deserializing has to be more precise.

serializing and deserializing to MD should be easy I think since all we need to do is read in headings and list items into lists with some denotation to the type it was.

Those are just my thoughts on the topic. My thinking has been I have gotten fed up with emacs modes that are good and a lot of effort to write but just end up adding a lot of stuff on top that make it difficult to customize or customize the the standard way and returning to simple lists could be good.

You might just as well require a sqlite db as the persistence layer. Emacs has always been about using plain text files as both data and interface while lisp is the control mechanism.

That’s why you got org files and a handful of lisp functions to turn them into a living documents. Using lists take that aspect away while markdown is just not that good to serve such a role.