BUG: Removing a submodule with --cached doesn't stage changes to the .gitmodules file

Removing a submodule with --cached doesn't stage changes to the .gitmodules file

Command:
`git rm [--cached] some_submodule`

Behavior without `--cached`:
- `some_submodule/` is deleted.
- The entry for `some_submodule` is deleted from `.gitmodules`.
- Both changes are staged.

Expected behavior with `--cached`:
- Neither `some_submodule` nor `.gitmodules` are actually modified in the work tree.
- `some_submodule` is staged for deletion.
- `.gitmodules` is staged for modification (removal of the entry for `some_submodule`).

Actual behavior with `--cached`:
- Neither `some_submodule` nor `.gitmodules` are actually modified in the work tree.
- `some_submodule` is staged for deletion.
- **`.gitmodules` is not staged for modification.**

Git version:
Seen on git 2.25 (Linux) and 2.16 (Windows)

Workaround:
- I had to `mv` the directory outside of the project, `git rm -f` it (without `--cached`), and then `mv` it back into the project in order to have `.gitmodules` changed without actually deleting the `some_submodule/` subdirectory.
- Alternatively, manually edit `.gitmodules` and remove the submodule (this isn't a viable option for automated scripts, and can be a bit inconvenient when the `.gitmodules` file is too big).



Example code:

mkdir some_submodule
cd some_submodule
git init
echo hello > hello.txt
git add hello.txt
git commit -m 'First commit of submodule'
cd ..
mkdir top_repo
cd top_repo
git init
echo world > world.txt
git add world.txt
git commit -m 'First commit of top repo'
git submodule add ../some_submodule
git status  # both some_submodule and .gitmodules staged
git commit -m 'Added submodule'
git rm --cached some_submodule
git status  # only some_submodule staged

Best regards,
        Javier Mora