Thank you for that helpful info/clarification!
Agreed on HTML standard and <style> element location.
With that fact noted, markdown itself is not legal/rendered in standard HTML (requiring pre-processing). Markdown pages are often fragments without direct mapped correlation and HTML page layout structure of html → head+body → etc. Hoisting style fragments is common practice in partial/fragment composition of web-pages.
As a related standards practice, it’s common in working with newer HTML/Web composition patterns to make use of custom-element techniques. Those publishing/generation facilities standardly make use of private shadow-dom CSS; which includes most modern browser themselves in how they provide standard DOM features (which is easy to see in their webpage-inspectors).
For custom elements the shadow DOM CSS is fully nested and encapsulated within the Custom Elements node subtree. In other words, locality of reference placement which is not code-design-tool constrained by the HTML standard of style element placement in the head.
Which is my 2-cents that the HTML standards regarding <style> location should not be of significant relevance to constraining an evolving markdown document authoring and publishing design.
The deeper thing I am exploring in Obsidian is what are its current capabilities for aggregation and composition of content and pages built from a markdown/YAML/HTML core. I am trying to see if I can use it for the toolsets and publishing patterns I already have for managed site workspaces whose content and structure is primarily described in wiki/markdown style.
With regard to interleaved HTML and markdown, the objective is to allow an html element to be used as a CSS (possibly JS) managed container but have the majority of its sub-content be authored in markdown. Which happens to include micro-web-service api capabilties.
organizationally a page might look this
---md-doc-begin---
some section (html-element containing markdown)
another section (html-element containing markdown)
another section (referencing/including another markdown document fragment inline on the fly)
---md-doc-end---
(somewhere) css (w/optional js) to handle the page presentation lifecycle [typically a renderer/template. The css will than position the sections however it desires within the markdown container element.
This would, for me, allow using Obsidian for CMS style authoring epub, dynamic sites, and more with almost any presentation view that one might see in reactive-responsive site designs.