Yes, it would be absolutely a good idea to collocate several large-scale projects within a single monorepo, because that immediately removes obstacles for reuse, maintenance and collaboration, and things that change together should go together.
Since you're in the best position to understand what your needs are, and given how you've stated the post, you already have the right answers to your questions, and I am assuming here what might be missing in your case is just resolving any remaining uncertainties and working out the details.
I can affirm that, and also offer the most challenging case for your solution, which should hopefully give you an idea of how you can best approach these questions.
Is this sane?
When you have multiple repositories, what makes them distinguishable from one another is that each has a unique base path, e.g. acme/frontend, acme/backend, etc.
Collocating everything under a single monorepo, say acme/omni, is just a slight shift of appending a common base path to all the changes therein.
To state the obvious, code doesn't suddenly lose the ability of being uniquely qualifiable. So if you think of this as a more general relationship, what holds true for code holds true for X, then and now, then, by virtue, you can still have independent code ownership, builds, deploys, rollbacks, issues, pull requests, project boards and everything else that's already available to each project on it's own, on the platform you're collaborating on.
To be realistic about these things, note the fine point on everything that's already available. If you cannot have some people see and not see some part of a project's repository they're working on, as is usually the case, then you can't expect to have that in a monorepo either.
What are the best practices?
Essentially, do as you would to make each project a success, except now there are no immediate technical limitations to make changes in a manner that addresses the needs of all the projects together.
So, if you went down this path because you realized there's things that would be good for more than one project, you already are the kind of a person that can look at these efforts as being best addressed form a unified whole, and that's the only thing that matters.
Hard case: some projects will need to exist outside the monorepo
What makes it hard to have a project existing in a separate repository is that everything you've tried to avoid with the simplicity of having a single monorepo now needs to be managed.
However, what gives an upper hand to someone tackling this from a monorepository is that everything within is already neatly modularized and disaggregated, due to the lack of technical restrictions, so it's a matter of adding support for such integrations on top of a sound base, whereas someone who finds themselves in a zoo of repositories needs to go through all the modifications to introduce sanity beforehand.
This is a long list of things and all of them are non-trivial, but basically everything tangible from your monorepo, the culture, chores, infrastructure code, build configurations, common libraries, services, assets and so forth, now need to be set up in a way that they can be made accessible to remote repositories.
In this, when it comes to everything that falls under VCS in particular, aside from the more traditional approaches of using some form of native capabilities to reconcile changes happening separately between independent repositories, or just degrading back to naively copy/pasting things all around, emerging tools like projen can be used. Much in a way a compiler can bootstrap itself, a monorepo applying projen onto itself can self-bootstrap, then proceed to automatically manage other repositories.
Personal musings on the matter
Good practices should not and cannot wait months or years to propagate and come into effect. This is mandated by the outside world, and so modern-day technologies already come out with support for all members of a single organization to work together in a way that when one unit strikes gold we are zeroing on having this instantaneously available to everyone else.
The monorepo is one such device, a very simple and effective one, one of many, and yet there's still a prevalent misconception that we absolutely need to have repositories such as acme/frontend and acme/backend.
This is not true, and if done so it should be only because it is instrumental, because it cannot be done otherwise, legal reasons being one good example. Making claims that there are prohibitive technical issues, such as "it's not going to be possible to do X separately in a monorepo, like we can now" in these cases is a false dichotomy. I find it a tough pill to swallow with how we still seem to love our islands and silos, while paradoxically we are giving it our all to give everyone the best support they need to do their job right.
