I know dolphin, at least, is subject to the same shader stutter that emulators for newer platforms are (if I understand correctly it's a shader per set of TEV parameters, or something like that), with the only real mitigation being that they've been able to write an "ubershader" that can (slowly) emulate the whole TEV pipeline in software for impacted pixels while they generate and compile an optimized shader in the background. Obviously Nintendo would probably ship shader caches to address the problem of having to generate them on the fly, but apparently the reason why dolphin has to do this is because games can just reconfigure the TEV with no warning and get results basically instantaneously. That definitely sounds like dynamism to me, but I don't know how it maps to this new extension.
As for why they might choose to use Vulkan for their BC layer, I think future proofing may be a compelling concern there, as well. I doubt that they'd go with a fully generic solution for performance reasons (in particular, the shader translator itself seems likely to be highly specialized), but keeping it as generic as possible while meeting their performance goals means less work bringing it forward beyond Drake. As time goes on, they could just Ship of Theseus it into a full on emulator the more that their hardware drifts away from the TX1. As proposed by @LiC, there's a certain appealing logic to using custom, highly hardware specific APIs like NVN in the moment to make games, while using more open standards like Vulkan to preserve them. Nintendo's got a good thing going with Nvidia right now, but they also had a good thing going on with IBM/AMD until one day it wasn't going so good anymore, and as you pointed out, they had to eat a fairly costly transition. In this current environment of much more expected BC, designing with an eye towards the longer term is probably a wise move.
