(j3.2006) Locality problems not repaired at Garching

[Van Snyder]

These might be nothingburgers, but they weren't discussed at Garching,
and I can't find convincing answers.

C1129 says that if DEFAULT(NONE) appears in a DO CONCURRENT statement, a
variable that appears in the block of the construct and is not an index
name shall have its locality explicitly specified.

Does a variable declared in a BLOCK construct within a DO CONCURRENT
construct, or the associate name in an ASSOCIATE construct, or a
statement entity such as an <ac-do-variable>, appear in the block of the
DO CONCURRENT construct?  That seems to be the case.

It seems absurd to require such a variable to be declared in the
enclosing scope, and then declared to have some specific locality, and
then declared in the BLOCK construct, wherein it behaves as though it
had local locality, but with possibly different characteristics,
notwithstanding the locality spec.

In C1129 do we need to insert ", is not a statement or construct entity
of a statement or construct within that construct," after <block> of the
construct" giving:

"C1129 If the <locality-spec> DEFAULT ( NONE ) appears in a DO CONCURRENT
       statement, a variable that appears in the <block> of that construct,
       is not a statement or construct entity of a statement or construct
       within that construct, and is not an <index-name> of that construct
       shall have its locality explicitly specified."

Is a variable permitted to appear only within a BLOCK construct within a
DO CONCURRENT construct that has DEFAULT ( NONE ) if IMPLICIT NONE is in
effect?  This rests upon a deeper question that might be addressed
somewhere, but I couldn't find an answer: If an implicitly-declared
variable appears only within a BLOCK construct (or several disjoint
ones), is it a construct entity of that (those) BLOCK construct(s)?  In
particular, if it appears in several disjoint BLOCK constructs, is it
the same variable in all of them, or a different variable in each one?
Does 3.39 make it a different variable in each construct?

If a variable specified to have local locality is the name of a common
variable, is it still a common variable?  The word "common" does not
appear in subclause 11.1.7.

What is the relationship between locality specs and implicitly-declared
variables?  C1124 doesn't illuminate this question.  If a variable is
mentioned in a locality spec but does not appear in the scoping unit
containing the DO CONCURRENT statement, is it implicitly declared?  If
it has local locality, it is a construct entity, and has a scope of the
construct, so it can't be implicitly declared in the enclosing scope.

If a variable has specified locality, does it have the same locality in
a DO CONCURRENT construct within the one where it is declared to have
that locality if the inner one doesn't have a locality spec?  How about
if it has a conflicting locality spec?

One might argue that some of these problems don't arise because
variables with local locality are construct entities, but C1127 clearly
contemplates some relationship between variables with local locality and
the ones from which they get their characteristics, in that it prohibits
ones that are prohibited from appearing in a variable definition context
(e.g., a variable with INTENT(IN), or one with the PROTECTED attribute
and accessed by use association) from having LOCAL locality.  This
suggests they're not construct entities, notwithstanding that 11.1.7.5p2
says they are.  Oddly, after C1127, 11.1.7.5p2 says a variable with
local locality does not have the PROTECTED or INTENT attribute.

These problems were pointed out in 17-144r1, which apparently nobody
read beyond the subject line.