Question: Should this PR also include cases where these new loading strategies are leveraged in core? Or is the thought that the PR be kept purely for the API changes and then to have separate PRs opened that make use of it?

@westonruter The latter, once the API is in core, we can start using it in a few places in core as well as the default themes.

Update: Comment moved to WordPress#4391 (comment).

When reviewing this PR, I was noticing how methods in WP_Scripts construct a lot of <script> tags manually with string concatenation, printf, variable interpolation, and calls to esc_attr()/esc_url(). Since WordPress 5.7, there have been dedicated helper functions (wp_get_inline_script_tag() and wp_get_script_tag()) which do all of the heavy lifting, as well as adding features like allowing the attributes to be filterable (for the sake of CSP). I've opened a draft PR (#58) for this branch which proposes using them. If desired, I can fix up the tests.

@adamsilverstein Do you know why these functions weren't utilized in WP_Scripts when they were introduced? I seem to recall this was punted for a later effort, but I can't find that info off hand.

Small spacing nitpicks

Resolved in recent commit @joemcgill

@10upsimon I believe we've wrapped up all blocking feedback on this draft PR at this point. When you're ready, please feel free to open a new PR to merge this branch into the trunk branch of the WordPress repo instead of this fork, and then I'll close this PR. We can pick up conversations about any additional enhancements we want to make (like #58) in the new PR that you open.

Closing this in favor of WordPress#4391, but we can still reference the open conversations and pick them up on the new PR opened against the WordPress repo.