(j3.2006) (SC22WG5.5641) Is LOCK_TYPE still not locked up?

[Van Snyder]

In C1305 (C1303 in 10-007r1), a named variable with a declared type of
LOCK_TYPE (Corrigendum 4 introduces "declared") shall be a coarray, and
a named variable with a noncoarray subcomponent of type LOCK_TYPE shall
be a coarray.

6.7.1.1p4 says the <source-expr> in an ALLOCATE statement cannot have a
subcomponent whose dynamic type is LOCK_TYPE.

I hope we don't allow this, but I don't see where it's prohibited:

type :: T1
end type T1

type, extends(t1) :: T2
  type(lock_type) :: L
end type T2

type :: T3
  class(t1), allocatable :: Q
end type T3

type(t3), save :: V3[*]
type(t3), allocatable :: V4[*]

allocate ( type(t2) :: v3%q )

allocate ( v4, source=v3 )

The problem (if there is one) arises because the definition of
"subcomponent" stops at allocatable components.

The declaration of V3 doesn't fall afoul of C1305 because it doesn't
have a potential subobject component of type LOCK_TYPE.

I don't think the allocation of v3%q with type(t2) violates 6.7.1.1p4
because it's not a <source-expr>.

I don't think the allocation of v4 falls afoul of 6.7.1.1p4 because v3
doesn't have a subcomponent of whose dynamic type is LOCK_TYPE.  V3 is,
however, of a type that has a potential subobject component of type
LOCK_TYPE.  Does 6.7.1.1p4 need to say that instead of "subcomponent"?
If so, we still need to do more work on Corrigendum 4.