FW: Bug Report: changes to submodule's files can be silently lost forever

Thank you for filling out a Git bug report! Please answer the following questions to help us understand your issue. What did you do before the bug happened? (Steps to reproduce your issue)

- I used the command "git config submodule.recurse true" in my top-level repository
- made a change to a file in a submodule (located within my top-level repository)
- performed a git checkout in the top-level repository to a commit that didn't have the submodule
- performed a git checkout in the top-level repository back to a commit that does have the submodule

What did you expect to happen? (Expected behavior)

When attempting the first checkout (i.e. to a commit without the submodule), I'd expect an warning telling me that the submodule was not up-to-date (uncommited changes). 

What happened instead? (Actual behavior)

The changes to the file in the submodule were lost forever without any warning

What's different between what you expected and what actually happened?

My uncommitted changes were silently lost forever, whereas I'd expect either 
- to be warned before I could continue or
- the uncommited changes to be retained.

Anything else you want to add:

Please review the rest of the bug report below. You can delete any lines you don't wish to share.

[System Info] git version: git version 2.29.2.windows.2 cpu: x86_64 built from commit: 3464b98ce6803c98bf8fb34390cd150d66e4a0d3 sizeof-long: 4 sizeof-size_t: 8 shell-path: /bin/sh uname: Windows 10.0 21292 compiler info: gnuc: 10.2 libc info: no libc information available $SHELL (typically, interactive shell): <unset>

[Enabled Hooks]