I think there is probably a lot of mileage that can be gained serving markdown over gopher with embedded gopher:// hyperlinks and images and utf8 and everything

I think there is probably a lot of mileage that can be gained serving markdown over gopher with embedded gopher:// hyperlinks and images and utf8 and everything else markdown supports via gopher itself. Gopher0 already has sort-of support for HTML file types so this would not be such a wild divergence from the original design. Not serving HTML provides some basic guarantees (no JavaScript, no tracking pixelsnetc) Gopher+ allows for quite flexible (albeit clunky) attributes for menu items so I can imagine an attribute on a menu directing compatible browsers to the markdown version of the menu, but allowing old clients to just view the traditional menu. This kinda relegates the gopher menu to a sort of old school directory listing type things we used to see in HTTP, but there is room for some fanciness via gopher+ to style menus themselves if browsers support that too! All of this is possible in Gopher+ if clients support it (...and there is an appetite for it). Perhaps we need some sort of "agreement"/Python-PIP-style thing to define sets of common Gopher+ attributes for all of this sort of thing.