I wouldn’t word it that way. It’s 4 different VEs, each can run the same Django project. (or different projects)
I don’t. That’s not something I worry about. My VEs are more closely associated with a deployment environment than a project. And since I’m typically working on something specific for a particular environment, I know which VE I need to use.
They’re just other Django apps within your project. (And I’m using the term “app” here in its very specific Django meaning. See Applications | Django documentation | Django)
Having additional apps in your project is not a requirement - In fact, I’m a member of the “One app until it hurts” club. Other people have other opinions on this point.
If necessary, document it in a README file. Don’t rely upon naming conventions.
The folders aren’t “doubled”. The folder names are reused. Those two directories - while named the same - perform two different functions.
That may or may not work out well for you. I don’t see that as (fundamentally) any different from those who include their VE within their Django project. Whether or not that works depends upon how you’re going to deploy this.
And that, I think, is a key point that might be overlooked here. I’m getting the impression that you’re trying to “optimize” your development environment, without figuring out what’s going to work for you in your production environment.
If you pick a directory layout that works for development but doesn’t work for your production systems, then you’ve wasted a lot of effort setting it up.
It’s a convenience for the Django startproject command and the person using it. It’s one command with one parameter that sets up the outer “project” directory and the inner “module” directory. There have been other discussions here (e.g. "Project" Naming Conventions) that talk about the naming of that inner directory. We’ve just never found it bothersome enough to worry about it.