My simple understanding is that it is quite possible for modern hardware to have clock rate well inside the range of most integer types and probably all real ones. So if the platform provides more than one clock, the only way to distinguish the user’s demand is to use the bitsize of the type. I would use solely the RATE for that, with some default (like standard REAL/INTEGER type) if omitted but it may be too late to introduce such a clarification of the rules.
But RATE can be either real or integer, so there would need to be some coordination between the various real kinds for RATE and the various integer kinds for COUNT and COUNT_MAX. And the other complication is that whatever is done in the future would need to be consistent with legacy codes.
In hindsight, I think the best approach would have been to allow only integer arguments, to require all the kind values for all the arguments to be the same, to represent RATE as a pair of integers (the numerator and the denominator), and to have a separate integer that counts the number of clock rollovers. Any subsequent floating point conversions could then be done by the calling program. One way to implement all of those together would be to have a single derived type argument where the integer kind of the components is defined by the compiler, not by the programmer. Then there would be no possibility of any type+kind mismatches or mismatches of the tick count from one clock combined with the rate for another clock.
But what should be considered legacy code if Standard, as it is now, does not say anything specific about treatment of arguments (in terms of choosing one or another clock), leaving that to the processor. So we are already in a situation where programs using system_clock() are not portable.
One could think about something like
clock = selected_system_clock(min_rate)
if ( clock < 0 ) then
clock = 0 ! select default clock (0) or try selected_system_clock(lower_rate)
endif
!...
call system_clock_new(count, clock)
but that, of course, would require quite new stuff in the Standard.
all three arguments are optional, but are not all three required to be the same type, so using the kind of any argument to select the resolution becomes ambigious.. That is a flaw in the design.
I made a procedure that called DATE_AND_TIME and used SYSTEM_CLOCK only to calculate the fraction of a second, whih eliminates worrying about rollovers on the SYSTEM_CLOCK counter and was thinking about DATE_AND_TIME having a ninth parameter in the returned array that would tell you how many digits were significant in the eight value but SYSTEM_CLOCK is most useful when measuring very small durations of time and I found calling DATE_AND_TIME and manipulating the data was taking a large enought duration of time to effect the resulting value. I otherwise was liking the idea.