My 2 cents: Potential new customers that would use Elements is far more important than a poll of the existing customers. And comparing the “feature” of a faster developer experience to a “feature” that doesn’t exist now but will sell more software is apples-to-oranges.
I am in the process of deciding between Elements and Hugo for my news and opinion (CMS) web site. I bought Elements but was dismayed by its CMS and Markdown support. The decision is yet to be made.
Strange comment. Hugo is, to me, a geekier way to do the same thing as Elements with Markdown. I looked at Hugo for a long time before realizing that Elements does a better job of surfacing the actual design of a static site running Markdown. Given what we’ve just seen about next week’s Elements 2.0 release, much of the naive Markdown support in Elements has been given a relook and now the CMS and Typography Components should now be in alignment. The only missing bit is deploying a stand-alone “write a post” application, and we’re promised that’s coming.
But for someone writing CMS in Hugo versus Elements themselves, it’s really the same: you build the structure, you populate the structure (add folder, add new file, etc.). The difference comes in the styling (design). Hugo is, like I said, geeky. Elements exposes styling in a much more user-friendly way.
That said: whatever modern Web application tool you decide to use will absolutely require some time to understand and learn. We’re a long way from simple HTML these days. It’s a bit like the difference between MacPaint and Photoshop ;~). Sure, we’re still just doing things with pixels, but in one we have to work directly only in pixels (HTML), while in the other we have tools that provide way more capability to do things with groups of pixels (CSS, Tailwind) or even process (Alpine, JS, etc.).
Maybe it’s the “naive” Markdown that makes Don think Hugo is better? 
One of the considerations for using something like Hugo is the ability to automate much of the publishing process through CLI scripting or similar. The thought process is this: a third party author creates an article in markdown, submits it to the editor/publisher (me or another person) who reviews it with minor corrections/changes (using Typora or similar), then runs a script which integrates and publishes the article, including front page excerpt, the article page in full, and index/archive pages. It will primarily be text oriented with a few images (graphs and such). The functionality of the web site is more important than a pretty design, although design is important as the content gets more varied and the web site reach expands. Note that it won’t be completely static - there will be odds and ends that come and go on the home page which would be more easily integrated with Elements. The publishing work flow will be heavily automated. The automation will cause emails to be sent to subscribers and headlines to be posted on social media. One difference from today’s world is that there will be NO reader comment section anywhere - think traditional letters to the editor as the feedback/comment mechanism.
Yes, I’m naive - I’m not a hard core web designer. I’m an old programmer with lots of scars to prove it.
Again, I looked at Hugo. Yes, you can script it to get it mostly automated, but that’s a bit of work. If the Markdown document is already on my Mac, I can use other Markdown tools to do any editing, save the file locally, then drag it into Elements. I wish that Elements supported Shortcuts, in which case it would be even easier. But again, I can deal with the short term pain knowing that the better case is coming later this year.
Typora is nice, but note that it doesn’t append .md as an extension.
From your description (“…including excerpt, article in full, index/archive”) I can see that you don’t fully understand Elements CMS. Once those are done once in your Elements site design, just dragging the .md file in will accomplish the same thing. It also supports “timed” publishing.
You might have noticed my post on AT Proto elsewhere. What you’re trying to accomplish already exists in the WordPress world, and the API is openly available, so I’m hoping someone will glom onto that. Dave Winer, the originator of RSS, is trying to do something similar with Wordland and its relatives. There’s little doubt that the multiple author, multiple outputs scenario that Dave and others (and apparently you) want will move forward. I’m just trying to make sure that Elements gets involved with that, because the power of many-to-many via HTML is what we all envisioned back when we were playing with Arpanet, and even before that with Ted Nelson and his Xanadu project.
The thing that always seems to get left out of the discussion is “design.” As in “what the user sees.” A buddy of mine who was one of the most influential in software designs points out that most people are still thinking way too narrowly. What does your “site” look like on those door-to-door LCD panels on current Mercedes? When used in PIP? When it’s on airline seatbacks (the airlines “fixed” this by using standard panels, but that’s not the perfect design). I look forward to Tailwind managing my watch ;~).