[Breaking API Change] Is this the right choice to make? One alternative could be to rename it to elementDeclarations with a type like readonly (ParameterDeclaration | TypeNode). My hunch is that that would be preferable, but I'm going with this smaller change for now to make reviewing easier.

Renaming it doesn't feel like a good idea compared to this; I assume that this array is indexed such that there are empty spaces where there are no names?

I assume that this array is indexed such that there are empty spaces where there are no names?

To the best of my knowledge - yes. There are a couple of places in this PR where it seems to be handled this way

What would the alternative be if not an array with missing names?

I think that most implementations that would include keeping labeledElementDeclarations with partial labels could be considered a breaking change. Even if you somehow omit undefined positions you still end up with a .length mismatch between those and other properties and that would be rather disastrous.

I think the current structure of this object makes the most sense but if you consider it to be too big of a breaking change then I think a different property should be added when mixed labels are involved and this one should be kept as undefined in such situations. That will be inconvenient to work with but if maintaining a backward compatibility is the goal then I don't see any other straightforward way of achieving this.

As in, this array seems to be the only one in the interface which actually describes each element; if we were to keep this array without making elements undefined, then the only thing I can think is that all of the named members gets smooshed up together, except now their indexes are lost.

So, it seems to me that the change in the PR is the least breaky option when we're now saying that something can potentially be undefined, because otherwise someone may iterate over this list thinking they're seeing everything, right?

Sorry, I mean "what would the alternative be if not an array which can contain undefined?"

I was responding to exactly that but perhaps I wasn't super clear. Should I try to rephrase my original answer?

if we were to keep this array without making elements undefined, then the only thing I can think is that all of the named members gets smooshed up together, except now their indexes are lost.

yeah, that would be IMHO bad - I mentioned that here: "Even if you somehow omit undefined positions you still end up with a .length mismatch between those and other properties and that would be rather disastrous.". But right now one alternative option comes to my mind - the missing labels could be prefilled with some defaults. You already generate such things for function parameters and stuff at times, like arg_0, etc, or something like that.

I know we generate synthetic nodes for names for stuff like declaration emit, but do we commonly store them in the types? (I genuinely don't know the answer!)

I don't know that either and perhaps you don't ever do that right now. I prefer to leave those optional members as undefined, that's just an idea that would help you to minimize the impact of this change if you think that this is a strong requirement for this PR to land.

I think we're agreeing? I think I too prefer to make them undefined just like this PR does; I just wanted to make sure that was the best choice given the break. Reasonably no matter what, if downstream users care about this particular bit, they're going to have to fix their code.