I'd love to see (or do myself if I ever get the chance) some research into some of the hot-button software architecture, tooling and project structure topics that come up a lot here and in every team I've worked on. They always boil down to a religious debate with strong opinions on all sides, and everyone wanting to copy something they've read about how their favourite MAGMA company does it, but it feels like some of these should have empirically right answers:

1. Under what circumstances is a monorepo beneficial as opposed to multiple smaller repos and what are the determining factors? (Team size, codebase size, tooling, software coupling, project velocity, .... etc?)

2. Under what circumstances are different system architectures better, and what are all the different factors that influence this? (eg microservices, 3-tier, one big blob of code, ... etc)

3. Can we empirically measure or determine whether a language, framework, library etc is the right choice for a given situation and how might we do that? Is it possible to formulate rules to inform good decisions here or is it always going to be a matter of judgement?

4. How do different styles of working (Pair programming, scrum, TDD etc) affect team productivity, code quality, developer happiness, project velocity etc? What are the factors that make one preferable over another in a given situation?

5. What's the right team size for a given project?

6. What's the best way to discover and communicate software requirements?

...

I could go on. But in other engineering disciplines, a lot of the analogous things are solved problems rather than being topics for heated debate.