I think most of the rationale behind flake design is ultimately documented in the RFC that originates it all: [RFC 0049] Flakes by edolstra · Pull Request #49 · NixOS/rfcs · GitHub
The rationale is effectively that large flakes are expected, and if you need to evaluate a large tree of potentially nested objects, the operation becomes really expensive. You then end up with the problems nix-env -q has.
If you instead limit it to one layer of attributes, you only need to parse attribute names (and not actually evaluate anything), so your nix info and nix search can stay spiffy.
There are probably other ways to avoid this too, but this is the approach that was taken. Flakes are still not finalized, and this is one of the major painpoints, so it may or may not change. Realistically, I doubt it will, the other painpoints will be resolved with flakes depending on other flakes.
To achieve your goal, the de-facto idiomatic solution is to just have multiple packages that override one at the same level and name them e.g. somePackage_latest and somePackage_11_0_2. If you look around nixpkgs, that’s anyway how this has been done even since before flakes (e.g. for the linux kernel, python, java, …).