When the selector in a SELECT TYPE construct is the result of a pointer-valued function it should be considered a variable with the POINTER attribute accordiing to R602/C602. It follows then from 8.1.3.3 that the associating entity should have the TARGET attribute, but the 13.0 compiler fails to do this. I've attached a small example the illustrates this bug and gives a bit more detail.

Actually you're right that my example isn't standard conforming, but not for the reason you cite. In my zeal to strip the example down to the bare minimum I wound up with a CLASS IS (INTEGER) which is illegal (intrinsic types not allowed in a class is --- an error that the compiler should have detected). I've attached a fixed example, and my original assertion that the compiler has a bug remains.

I'd agree with your analysis if this were a pointer assignment statement, but it's not. This is a SELECT TYPE statement and there are a whole set of rules that apply to the associate-name (which is not a data-pointer-object):

16.4.7: "The associate name of a SELECT TYPE construct has a separate scope for each block of the construct. Within
each block, it has the declared type, dynamic type, type parameters, rank, and bounds specified in 8.1.9.2."

For the type(integer) block 8.1.9.2.5 says: "Within the block following a TYPE IS type guard statement, the associating entity (16.5.5) is not polymorphic (4.3.1.3), has the type named in the type guard statement, and has the type parameter values of the selector.

And for the type(foo) block 8.1.9.2.6 says: "Within the block following a CLASS IS type guard statement, the associating entity is polymorphic and has the declared type named in the type guard statement. The type parameter values of the associating entity are the corresponding type parameter values of the selector."
So in this case the associate name is either polymorphic of class foo or of type integer depending on what block gets executed.

But the important bit is 8.1.9.2.8 which says: "The other attributes of the associating entity are described in 8.1.3.3" which leads back to my original assertion that the associate name has the TARGET attribute, for 8.1.3.3 says: "The associating entity has the TARGET attribute if and only if the selector is a variable and has either the TARGET or POINTER attribute."

To which statement do you think C715 (R733) applies? I think you're looking at

select type (uptr => return_uptr())

and thinking that "uptr =>return_uptr()" is a pointer assignment statement; it's not and C715 (R733) does not apply. It uses the same kind of syntax but it is something else entirely. It is called a construct association: see 16.5.1.1 and 16.5.1.6. My (fixed) example is standard conforming, and I reiterate that there is a bug, but it's not what you're going after.

To be clear, I agree with you that there is a bug in how our compiler is handling objects passed through a class(*) pointer. Changing the code as I have suggested does not cause the error mesage to go away.

Ah, I see what the confusion is. You've got things backwards. In the statement

uptr => obj

uptr is the data-pointer-object and obj is the data-target (see R733 in 7.2.2.2). The data-target here is not unlimited polymorphic, it's a non-polymorphic variable with the target attribute, and so C715, "If data-target is unlimited polymorphic, ..." doesn't apply to this case at all.