Non-default I/O kind fails

[JFH]

This program runs correctly with gfortran, but ifx won't compile it.
```
program iso10646 ! shortened from @urbanjost's program in Fortran Discourse
! "How to use utf-8 in gfortran". Fortran 2003 or later.
use iso_fortran_env, only: output_unit

integer, parameter :: ucs4 = selected_char_kind ('ISO_10646')
integer, parameter :: utf8 = selected_char_kind ('UTF-8')
character(13) :: OK(2) = ['supported ','not supported']

print *,'ISO_10646 is ',OK(merge(1,2, ucs4 >= 0 ))
print *,'UTF-8 is ',OK(merge(1,2, utf8 >= 0 ))

! an encoding option is required on OPEN for non-default I/O
open (output_unit, encoding='UTF-8')
! for constants the kind precedes the value, somewhat like a BOZ constant
print *, ucs4_'Hello = Ni Hao = '// &
char(int (z'4F60'), ucs4) // char(int (z'597D'), ucs4)

end program iso10646
```
Output from gfortran 15.1.0:
```
ISO_10646 is supported
UTF-8 is not supported
Hello = Ni Hao = 你好
```
Output from ifx 2025.2.0:
```
iso10646.f90(15): error #6684: This is an incorrect value for a kind type parameter in this context.
print *, ucs4_'Hello = Ni Hao = '// &
-----------^
iso10646.f90(16): error #6684: This is an incorrect value for a kind type parameter in this context.
char(int (z'4F60'), ucs4) // char(int (z'597D'), ucs4)
---------------------------^
iso10646.f90(16): error #6684: This is an incorrect value for a kind type parameter in this context.
char(int (z'4F60'), ucs4) // char(int (z'597D'), ucs4)
--------------------------------------------------------^
compilation aborted for iso10646.f90 (code 1)
```

[Mark_Lewy · Accepted solution]

In short, the Intel Compilers don't support the ISO_10646 kind, so selected_char_kind returns -1, which is an invalid kind type parameter.

Aside: I would be interested to know when or if Intel plan ISO_10646 support, seeing as gfortran, at least, has it.

[andrew_4619]

I wouldn't hold your breath waiting for 10646 support, the answer today is the same as when it was discussed on the forum 13 years ago. I can also see why it isn't a priority

[Ron_Green]

@Mark_Lewy thank you for answering this question.  And to your question, we have no plans for additional ISO character kinds at this time.  We do have an existing feature request for ISO_10646 kind, but we do not have the resources to address it anytime soon.