Not necessarily, you could as you mentioned have a separate PipelineConfiguration entity for each project. But each PipelineConfiguration entity that wants to share the config, could point at the same config bundle. If for example, you were using a path descriptor they could all point to the same config on disk, but the same applies to any of the other descriptors, such as git or shotgun upload, they could point to the same source.
This I think would be more work and becomes messy and confusing, but is doable.
You would have your schema set up so that the Sequence folder in the {Episode}/{Sequence}/{Shot} hierarchy only got created when an episode was provided using the filters.
- { "path": "episode", "relation": "is_not", "values": [ null ] }
And the reverse for the Sequence folder in the {Sequence}/{Shot} structure.
- { "path": "episode", "relation": "is", "values": [ null ] }
That would then mean you would need a set of templates for episodic and a set for non episodic. Note it is possible it define optional fields in a template using the square brackets syntax ([Epsiode] ) but this is only intended to make keys optional in the file name and not in the path, you would likely hit errors if you tried to make the episode field optional, so its best to have two sets of templates, episodic and non episodic.
That would then mean you would need to change your environment depending on whether it was episodic or not. And at that point, you would as you mentioned need to change the pick_environment.py hook to if the sequence had an episode, and then choose the correct environment accordingly.
This means that your environment files need branching depending on whether or not you are working with episodes. Option 2 in the post you linked could help make that easier, but in my opinion, I think what your trying to do with the schema means you are better off having separate configs.
I would be almost like cramming two configs inside one.
I hope that helps?