I think the code is generally looking good from a software perspective. With PR #1460, which went in to the v8.4.1 release and modified packages for various surface fields, I think there will now be merge conflicts with the develop branch. @joeolson42 would you be able to rebase this PR branch onto the HEAD of the develop branch to resolve these conflicts? Or, if you'd like, I can help with this, as I'm familiar with the changes from #1460 that caused the merge conflicts.

Also, to accommodate changes in #1460, I think we'll need to add 'sf_mynnsfclay' to the list of valid surface layer schemes in the logic for the sfclayer package.

I'll take care of it. I really like the idea of the sfclayer package--thanks for that! I'll fix the logic after the merge.

@mgduda About our conversation about QKE advection... It would be nice to get that in as part of this PR, but I'm not sure how best to do it. It would be nice to keep TKE advection as a namelist option in case it has numerical stability problems in regional domains, like it did in WRF (especially for level 3). But if we follow the way it was done in WRF:

1. we used an additional array (QKE_ADV) which is what was actually advected,
2. then QKE was set equal to QKE_ADV at the beginning of the MYNN-EDMF,
3. then QKE_ADV was set equal to QKE at the end of the MYNN-EDMF
4. (2) and (3) were only performed if the namelist variable "tke_advect" was set to true

This worked and we could continue with this method, but I was wondering if you had a cleaner idea that wouldn't require an additional array. Something to think about.