(modified content) note for a submodule does not distinguish between un-added and added changes to tracked content, which is confusing until you realise why that distinction is irrelevant here.
git add a submodule, what you're adding is its current commit id. That is what's supposed to be restored at the submodule path later, in other checkouts in other repos: that commit, the commit with that id. All that gets recorded in your own commit is the id of the submodule commit that should be hunted down and checked out there. If you want.
git status is telling you you've got some new submodule content that hasn't been committed yet. Git allows you to commit your added aka cached aka indexed aka staged content without regard to any subsequent changes in the worktree, which baffles and even angers people until they hit their stride on what you can do with that, but when you add aka stage aka cache etc a submodule, the added content is just the submodule commit id: there's a necessary little stutter-step in there if you're making new history in that submodule's worktree, you must add and commit your new content so you can stage the submodule's new commit id in the main index.
So whether or not you've
git added the new tracked content inside a submodule is immaterial to repos using that submodule, what matters is whether you've committed them, and
git status is telling you you have uncommitted changes to tracked content there.
You need to actually cd in to that submodule and (add, but you've already don that, and) commit its new contents. Then you can record the new submodule commit's id (the "I'm sorry, your content is in another castle" line) in the main repo's index before committing that. There's a reason
git submodule update --init --recursive isn't the default.