I suppose the above comment was about amdvlk. radv is indeed often ahead of it these days.
If anything, I think AMD should drop amdvlk on Linux (to collaborate on radv there) and instead try to develop radv for Windows if that's doable to replace amdvlk altogether.
Many of the people working on RADV are already employed by AMD (or paid by them indirectly), so arguably it's already collaborating.
I see the amdvlk/radv drivers a bit like the windows "Radeon Pro"/"Adrenalin" driver split, one is for people who stare at solidworks all day, the other for everyone else.
I think AMD wanted to phase out that distinction for OpenGL for example, so why wouldn't they want the same for Vulkan There is no need for them to be different really in that sense.
amdvlk and radv exist for historic reasons since they started independently and amdvlk was designed to support Windows too. But today I don't really see a big point in admvlk except where radv doesn't exist.
So AMD can do what Intel does. Support radv on Linux and amdvlk on Windows for example, or as above, try to make radv work on Windows too.
If anything, I think AMD should drop amdvlk on Linux (to collaborate on radv there) and instead try to develop radv for Windows if that's doable to replace amdvlk altogether.