Update enhanced-parts/feature-specification.md

[lrhn]

Remove configurable part directives.

General tweaks and phrasing fixes, and some typos fixed.

Mention extension conflicts.
(You can break sub-parts by importing an extension that causes a conflict.
You can protect a part against that by using explicit extension applications.
Most people won't ever notice, extension conflicts are rare.)

[eernstg]

Maybe "assigned" should be "reviewer"?

[lrhn]

They should! And now they are.

[eernstg]

Thanks! I won't get around to it today, but tomorrow should work.

[eernstg]

Very nice!

I added a bunch of comments. I'd prefer if we're slightly more careful about the characterization of the current rules (it's not the purpose of this document to change the existing rules). Also, I find the use of the phrase 'combined import scope' confusing, and I'd prefer to have a characterization which is consistently based on a scope tree (where edges go from each scope to its enclosing scope). Also, a couple of questions arise when it comes to shadowing and prefixes.

I'd like to know whether there is anything in this specification which is intended to contradict the scoping structure which is shown at the top of #4082. Otherwise, that might serve as a checklist to consider at each step when reading the rules in this document.

[lrhn]

Nothing is intended to disagree with the diagram of #4082.

The library introduces:

• One declaration namespace for all the declarations of the library. (And not import prefixes of import directives.)

Each file introduces:

• One import namespace, for all the declarations of unprefixed imports of the file.
• One prefix namespace, for all the prefixes of the file.
• One prefixed import namespace per prefix, for all the imported declarations with that import prefix.

A file introduces one scope per per namespace that it introduces, with the following parent scopes:

• The import scope: The prefix scope of the parent file, if there is a parent file, otherwise none.
• A prefixed import scope for a prefix p: If the parent file's prefix namespace has a scope for the prefix p, then that scope, otherwise none.
• The combined import scope: Has the prefix namspace as namespace and the import scope of this file as parent scope.
  • The identifiers of the prefix namespace are bound to the prefixed import scope of this library for that prefix.

A file also has a top-level declaration scope whose namespace is the library's declaration scope, and its parent scope is the file's prefix scope.

The text uses both "prefix scope" and "combined import scope" about the same scope, usually depending on whether the text focuses on the namespace or the entire chain. That's probably confusing, it should use the same name every time.

[munificent]

I didn't follow all of the details of the scoping rules but it seems like you and Erik are hashing that out fine. :) If you want me to dig in, let me know and I'll go through it in detail.

Otherwise, LGTM!

[munificent]

Nit: "APIs" -> "API's".

[lrhn]

A quick search suggests that "most style guides" recommend not using an apostrophe with a plural initialism.
The University of Oxford Style Guide agrees.

[lrhn]

Addressed comments. Will land on Monday if no complaints.