QLocale::FormatType has separate Long, Short and Narrow formats. It is used for querying the names of both days of the week and months, where all three are distinct, and to select the format to use when serialising a date, time or datetime; but, for formats and formatting, Narrow is just treated as the same as Short. See this documentation-change for discussion (and the change to documentation to be honest about the status quo).

For the formats, CLDR has several date formats (and the same for time and datetime formats). We currently use its full as our Long, don't use its long or normal and use its short for our Short and Narrow. We could conceivably use its normal for Short and short for Narrow; but would need to look at what actual formats that gets us in practice, to assess how disruptive that might be for code currently using Short (and ignoring Narrow because the authors knew that made no difference).

At present Qt's own date and time format strings only support long forms (MMMM and dddd for month and day names) and short forms (MMM and ddd). Extending to distinguish narrow forms would also run into incompatibility here, as shorter forms (MM, M, dd and d) are already in use (for numeric representations, either zero-padded when single-digit or not), so we can't use a shorter sequence for narrow format. Using a longer sequence would be confusing (as more repeats of a format character have previously meant longer forms, but this would use a longer format for narrow than for long) and changing the meaning of existing formats (e.g. to make three repeats mean narrow, four short and five long) would be a significant behaviour change, affecting code that uses its own hard-coded formats (notably many of our own tests). Introducing another letter for use in the narrow case then has its own problems. QTBUG-79902 could be an alternative way out of this.

It is possible, as a result, that fixing this would be too disruptive and we shall just have to endure the status quo.