This is issue can be considered future-proofing, since it refers to features that are only at the design stage now, but I wanted to at least bring it to your attention, even if it ends up being discarded in the end.

I noticed this bit as the motivation for the way located types are currently defined in the spec:

The lack of a stack or default location is intentional, but can be added if needed. The choice to separate the location from rest of the type was to avoid multiple descriptors for a struct depending on where that struct is located. Under this design, there is a single definition for the shape of the struct, and the different data locations of that struct are handled by located type descriptors.

Let's use this example for the sake of discussion:

struct S {
    uint x;
}

struct T {
    S s;
}

One of the upcoming changes in Solidity is making the location an integral part of the type. So you'll be able to have memory T containing storage S. It will be possible to express this in the spec as it is now, but will require interleaving located and non-located types. I.e. T containing located S based on plain S. Still, so far so good.

The potential future problem is that it is very likely that we'll want to keep things simple for the user and have the location "propagate" through nested types. So you would not have to explicitly define location for T.s. Instead T memory would imply that it contains S memory and T storage would implicitly contain S storage (unless explicitly declared otherwise). This, would make the types generic with respect to location and, combined with the interleaving I mentioned above, would break the assumption that you get one "shape" for the struct. If you do want to keep a single T in the type section that both T memory and T storage could refer to, you need to change how the type section works.

Again, I want to underscore that this is still at the design phase right now and just one of the possibilities and may have well changed since the last time we discussed it in the team. My intention here is to open a discussion on it rather than to treat it as an issue in the spec that needs a fix.