Both ifort and NAG have working implementations of PDT. A couple of weeks ago I dug up an old F90 PDE solver code from the late 90’s that used an “array-of-struct” type of data structure, similar to the OP’s example, pervasively throughout the code. Out of curiosity I modified it to be a PDT with length type parameter like the OP wants to do. (My experience has been that a “struct-of-arrays” data organization generally performs better than an “array-of-struct” organization, so this was just for fun.)
It worked just fine with the ifort compiler. However it was much, much slower – something like 8x slower. I have no clue why. But I recalled an email exchange I had with a NAG compiler developer many years ago, who strongly discouraged me from using length type parameters because of something intrinsic to them would necessarily make them relatively slow. I don’t recall the details now. If a compiler developer reading this could shed some light on this, that would be great.
I suppose kind type parameters can be somewhat useful if you don’t have type bound procedures (I almost always do). But if you do, you still have to write versions of the procedures for every kind you foresee using. You’d think that this could work like templating (only the kind is being varied, not the type), but no dice.
All in all, I find PDT to be a mostly unhelpful addition to the standard. This is a case where having an actual prototype implementation in some compiler would have been very helpful sanity check before adding it to the standard.