@mcc 
@whitequark✧✦Catherine✦✧ it is implemented incorrectly. it transforms operations—clone, merge, pull, checkout etc—which straightforwardly mean “make my working tree mirror the state of the consensus reality of the working tree at this revision” to instead mean some different thing where some mysterious additional command or commands must be run to finish syncing. this operation is the fundamental, most important thing that a VCS must do, so its failure provokes a very understandable negative reaction
@glyph @mcc @whitequark✧✦Catherine✦✧ I have found that there are actually some options that help here!
submodule.recurse true
This makes many of the pull/checkout/etc operations do what you mean recursively including submodules. You still need to do something to initially pull the submodules, this doesn't change the fact that submodule are something you need to opt into, and of course any commits you still need to deal with committing and pushing in the submodule before the parent, but it means that if you just want "when I checkout a new branch, also checkout the appropriate submodule commit for that branch" just work.
status.submoduleSummary true
diff.submodule log
These options provide better status information, so when you have some change in the submodule compared to what commit you're on, you can see what commits added/removed there are in the submodule, rather than just a couple of SHA identifiers.
These dramatically improve the UX of working with submodules. I still find that people reach for them too much, but they're more tolerable with these options. Not sure why they aren't on by default.
If you have a fediverse account, you can quote this note from your own instance. Search https://hachyderm.io/users/unlambda/statuses/116112626905410401 on your instance and quote it. (Note that quoting is not supported in Mastodon.)