Run Configuration safe placement ― in a nested projects context

Context and Overview
 

I have a python project which has a c++ project as a git submodule. So it is nested in a subdirectory of the python project. Further, I'm using the official now Jetbrains maintained Bazel plugin for the c++ project, and also have it installed in PyCharm though it goes by a slightly different name in PyCharm than its name in Clion is. 

There is also some nested rust code in the same python project which I use RustRover for.

PyCharm, Clion and RustRover work harmoniously for this setup; the root dir for each one is set differently within the nested project, and they interoperate well, excelling with git operation awareness to the nested (submodule) nature in the UI's wrapping around git; I marked all necessary nested dirs as excluded etc to avoid over-indexing etc.

How can I make PyCharm ignore or not get confused by run configurations of the nested projects?

technical detail

I currently have them run configuration files for some reason always within a .run/ sub-directory wherever they are, but just copying them to under .idea/ didn't make Clion acknowledge them and I'd rather stop my tinkering at this point in favor of authoritative info about considerations towards safe run configuration placement.

framed as a problem description:

Pycharm currently shows the run configs of my nested Clion and Rust projects as “broken” in the Run/Debug Configuration window. I don't deeply care if PyCharm showed run configs included in the nested projects as broken like it does, that's fine for me. 

But rather I am adressing this because earlier I had a single same-named config in different levels of the tree,  or just PyCharm had other issues with any of the nested configs, which caused inconsistent and quite blocking error messages in the Run/Debug Configuration window (the error messages were'nt saying anything about what is the underlying source of issue but were rather complaining about being unable to save a config even when not trying to save any). 

Which would be utterly confounding to other potential developers if it were to happen again, and I'd like to avoid future potential of such issues by learning of a better way of placement or configuration with nested projects each having its own run configs.
 

final comments

I'm using the latest version of each of these IDE and the plugins, other than beta and RC versions which I skip. 

The run configs are git managed by intent, and seamlessly use only user-agnostic data as such (e.g. the working directory always uses the allowed variable name which JetBrains IDE substitute). 

---

I thank you for your advice on both implications of placement of run configs, and towards the specific described setup of a nested project.