More on the markdown method
In my question I missed some prior discussion of the same topic, for example another UL question, Send email written in markdown using mutt. That question seems to be really about how to do this on a shared computer or some other situation where it is not possible to modify the "sendmail" used by Mutt, but it links to a solution which should fit my use case.
The solution is from 2009, from dgl.cx, HTML mail with mutt using Markdown, which binds a keystroke in the Compose screen to create a specially-named HTML attachment via a fake 'editor'. Then a fake sendmail, when it sees this specially-named HTML attachment, creates a multipart/alternative structure and passes it to the real sendmail.
One of the comments in the above UL discussion links a "No Substance" blog post, mutt's secret sauce, which I found very helpful as well.
Both approaches solve some problems that arise in more primitive treatments:
How to create proper multipart/alternative attachments. We would like to send multipart/alternative with both text/plain and text/html, so that people using Mutt can see the original source, and people using Gmail can see the HTML. Markdown is ideal for this in that the the source is also human readable. However, apparently outgoing mails with multipart/alternative structure have only fledgling support in NeoMutt. The dgl.cx post solves this problem by having a fake sendmail create a multipart/alternative structure. The No Substance post has a fake sendmail which additionally does the Markdown parsing. With NeoMutt's new support for multipart/alternative, maybe an even better solution will be forthcoming in which a fake sendmail will not be necessary.
How to allow previews. If we're going to be attaching an HTML version, which is easy enough by switching to an alternate Sendmail, then it would be good to see how this looks before the message is sent. As pointed out in the No Substance post, this can be done by monitoring the file in which Mutt stores draft messages, whose location is configured with the "postponed" variable. For the dgl.cx solution, this is not really necessary since the HTML version already appears as an attachment and can be opened manually.
I haven't tried either solution yet but I'm leaning towards the one from dgl.cx as it seems simpler.