How Feasible/Sane is it to have multiple unrelated projects in one Unity project?

I'm quite experienced with Unity and other (non-Unreal C++) game engines. I've managed multiple projects in C++-based engines, but with Unity in the past, I've used one shippable project per project folder. At the moment I have barely-related 3 multi-platform projects that share the same third party libraries, some common code, and a bit of overlap in visual resources. One is a pre-release game, another is a client project, and another is an internal prototype.

Currently, I keep these all in the same Unity project (containing Assets and ProjectSettings). Right now, to preserve build settings, I cache these files per-project:

EditorBuildSettings.asset
ProjectSettings.asset

I love the monorepo approached and I've used it extensively from solo teams to startups with dozens of people. When you're considering a change, you can easily search and compile everywhere it's used. You're forced to write code at the right level of generalization, and fixes in one project can benefit all projects in the same repo. However, I can't tell if Unity likes this approach.

I've seen people recommend use of submodules, or symlinking directories in the Unity project before. I've had bad experiences diagnosing bugs that have submodule dependencies. I'm cautious of a complicated symlink setup, as I currently use 3 machines (one macOS, two Windows) to build and test multiple types of hardware, and also have contractors use my repos occasionally.

So what are the downsides of having one big project folder for all my building projects? Two areas I'm concerned about are:
1) Resource folders that may needlessly be shared between projects when shipped.
2) Third-party libraries with unexpected effects. Currently, I'm planning to handle these with per-project compile flags.