Convention 1: High-level type directories, project sub-direc
[A partial answer.]
In "Convention 2: High-level project dirs, type sub-directories," your single con is
If there are dependencies between projects, you need an additional layer of build scripts above the project directories to manage the build order
That can also be viewed as a pro, in many projects.
If you have a lot of repetitive general definitions, one would probably want an include file for the build scripts, where solution-wide constants & parameters could be defined. So the "additional layer of build scripts" will frequently happen anyway, even if there are no (direct) dependencies.
It's a pro in that there's still room for a more modular approach in building. On the other hand, if you want to reuse a project in another, unrelated solution, you would need to compose a different definitions file. (On the other other hand, if there were a single build file for the whole solution, as in Convention 1, you would need a different build script.) As for your maintenance requirement, that's (IMO) very project-dependent.
My feeling leans towards Convention 2, but it's far from a clear win. In fact, your experience with Convention 1, which was working well until recently, may be the biggest pro of all: a team of people with experience with a certain organization is a valuable asset.
Consider using NTFS junction points so you can have both organizations at once. Quick definition: "a junction point is Microsoft's implementation of symbolic links but it only works for directories."
Use Convention 2 for the "real" layout, because it makes the projects easy to move around. Then make a Convention 1 view:
mkdir /solution/test
linkd /solution/test/prj1 /solution/prj1/test
linkd /solution/test/prj2 /solution/prj2/test
Now you have ...
/solution
/test
/prj1
/prj2
... which was the desired result.
You could do the same thing for /src or the other directories if you find it beneficial. Test scripts that benefit from a Convention 1 view live in /solution/test.