Stepping back a bit, I think we're struggling to ignore the elephant in the room. This elephant is the fact that there's no specification (or API) that defines (or provides facilities to control) when rendering happens. And for that matter, what rendering means.
The original reason why <script> blocks execution until imports are loaded was not even related to rendering. It was a simple solution to an ordering problem -- if I am inside a <script> block, I am assured that any script before it had also run (whether it came from imports or not). It's the same reason why ES modules need a new HTML element (or script type at the very list). Blocking rendering was as a side effect, since we simply took the plumbing from stylesheets. Then, events took a bewildering turn. Suddenly, this side effect turned into a feature/bug and now we're knee-deep in the sync-vs-async argument. And that's why all solutions look bad. With "elements" attribute, we're letting the user of the import pick the poison they prefer (would you like your page to be slow or would you rather it flash spastically?) With "sync" or "async" attribute, we're faced with an enormous responsibility of predicting the "right" default for a new feature. Might as well flip a coin there. I say we call out the elephant. We need an API to control when things appear on screen. Especially, when things _first_ appear on screen. :DG<
