Thanks for the measured response here.
I address the fact that the site, as it currently exists, doesn't need any of this currently. I tried to be clear in my "criteria list" that I'm designing for power and flexibility; I don't want to limit myself down the road.
I definitely could have verbalized my stance on headless CMSs better. I'm very aware that there are ways to use them without requiring two round trips. But in the very next paragraph I say "I want every page of my site to be pre-rendered to a set of fully static assets". The solution you allude to (a headless CMS with server-side rendering) requires a server and doesn't meet that criteria.
I also know you can do generate a static site with Next/Gatsby + a headless CMS that's integrated into your build step. I didn't do that way because it seemed overkill - I'm happy using my file system as my CMS.
You mention that I reject using "MD along with React". Which bit of the post are you alluding to? I do reject the idea of putting React components inside of `` tags inside of a Markdown file. Based on my criteria, the "React + a sprinkling of Markdown" makes more sense than "Markdown + a sprinkling of React". Otherwise it's an uphill battle (with a fair bit of boilerplate) to use React Hooks, import styling libraries, etc.
I'm not sure I follow your logic w.r.t this being a damning condemnation of React. There a build step (either Babel or TypeScript) required to use cutting-edge React. That additional layer of separation is what makes it so hard to do React+TS inside of these Markdown-centric CMSs. I don't think that impedance mismatch reflects poorly on either React or the SSGs - they each have their uses.
Could you elaborate on the "other, simpler options even within the TS ecosystem"?