That doesn't sound like a good idea. In particular the swapped notation `2024-05D-06M` allowed? Otherwise added suffixes purely exist to aid audiences, but that crucially depend on their background knowledge and English-based suffixes are not international enough. (Compare with ISO 8601 week date, where weekday is indicated by a single-digit letter and an additional letter `W` can be technically omitted for many cases.) If we can assume English, `2024-JUN-05` would be an even more clear alternative.
I agree that using `JUN`s makes it more clear as a non-native English speaker. What can we do without refering to some language? Maybe like 2024-[06]-05 or 2024-06-(05) (vs 2024-05-[06] and 2024-05-(06))?
Assuming that this is a real issue that should be fixed in the standards (which I don't agree, btw), I think the month should use a separate set of symbols to be distinct, which sadly implies some kind of additional knowledge besides from Hindu-Arabic numerals (but not necessarily English). A compromise can be also made if we all accept that month numbers can be arbitrary, e.g. 33--36, 43--46, 53--56 for 12 months. Prefixes or suffixes wouldn't work well because people would then confuse which one is month and which one is day of the month; by using an entirely different set of month symbols, a fresh connection can be made instead.
This is a proposal for an extended ISO date format. From the pains of my previous work experience, I saw, all other parts of the dates were quite unambigious, but when it came to month and date, the information is lost. There has to be some understood contract between parties to adhere to the formats. This is unnecessary. This date doesn't need to be widely used, but for b2b maybe, where we have to parse date from different vendors. Mostly none of the date formats deal with this. There is no way to tell 2016-01-02 is YYYY-MM-DD or YYYY-DD-MM
P.S. I took the help of GPT to fix the english in the draft.