Update docs on labels and annotations (#11719)

Be clearer about character set and a couple minor tweaks on words.

content/en/docs/concepts/overview/working-with-objects/annotations.md

@@ -53,11 +53,22 @@ Here are some examples of information that could be recorded in annotations:
 * Phone or pager numbers of persons responsible, or directory entries that
   specify where that information can be found, such as a team web site.
 
+* Directives from the end-user to the implementations to modify behavior or
+  engage non-standard features.
+
 Instead of using annotations, you could store this type of information in an
 external database or directory, but that would make it much harder to produce
 shared client libraries and tools for deployment, management, introspection,
 and the like.
 
+## Syntax and character set
+
+_Annotations_ are key/value pairs. Valid annotation keys have two segments: an optional prefix and name, separated by a slash (`/`). The name segment is required and must be 63 characters or less, beginning and ending with an alphanumeric character (`[a-z0-9A-Z]`) with dashes (`-`), underscores (`_`), dots (`.`), and alphanumerics between. The prefix is optional. If specified, the prefix must be a DNS subdomain: a series of DNS labels separated by dots (`.`), not longer than 253 characters in total, followed by a slash (`/`).
+
+If the prefix is omitted, the annotation Key is presumed to be private to the user. Automated system components (e.g. `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, or other third-party automation) which add annotations to end-user objects must specify a prefix.
+
+The `kubernetes.io/` and `k8s.io/` prefixes are reserved for Kubernetes core components.
+
 {{% /capture %}}
 
 {{% capture whatsnext %}}

content/en/docs/concepts/overview/working-with-objects/labels.md

@@ -10,8 +10,8 @@ weight: 40
 
 _Labels_ are key/value pairs that are attached to objects, such as pods.
 Labels are intended to be used to specify identifying attributes of objects that are meaningful and relevant to users, but do not directly imply semantics to the core system.
-Labels can be used to organize and to select subsets of objects.  Labels can be attached to objects at creation time and subsequently added and modified at any time.
-Each object can have a set of key/value labels defined.  Each Key must be unique for a given object.
+Labels can be used to organize and to select subsets of objects. Labels can be attached to objects at creation time and subsequently added and modified at any time.
+Each object can have a set of key/value labels defined. Each Key must be unique for a given object.
 
 ```json
 "metadata": {
@@ -22,7 +22,7 @@ Each object can have a set of key/value labels defined.  Each Key must be unique
 }
 ```
 
-We'll eventually index and reverse-index labels for efficient queries and watches, use them to sort and group in UIs and CLIs, etc. We don't want to pollute labels with non-identifying, especially large and/or structured, data. Non-identifying information should be recorded using [annotations](/docs/concepts/overview/working-with-objects/annotations/).
+Labels allow for efficient queries and watches and are ideal for use in UIs and CLIs. Non-identifying information should be recorded using [annotations](/docs/concepts/overview/working-with-objects/annotations/).
 
 {{% /capture %}}
 
@@ -47,8 +47,11 @@ These are just examples of commonly used labels; you are free to develop your ow
 
 ## Syntax and character set
 
-_Labels_ are key/value pairs. Valid label keys have two segments: an optional prefix and name, separated by a slash (`/`).  The name segment is required and must be 63 characters or less, beginning and ending with an alphanumeric character (`[a-z0-9A-Z]`) with dashes (`-`), underscores (`_`), dots (`.`), and alphanumerics between.  The prefix is optional.  If specified, the prefix must be a DNS subdomain: a series of DNS labels separated by dots (`.`), not longer than 253 characters in total, followed by a slash (`/`).
-If the prefix is omitted, the label Key is presumed to be private to the user. Automated system components (e.g. `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, or other third-party automation) which add labels to end-user objects must specify a prefix.  The `kubernetes.io/` prefix is reserved for Kubernetes core components.
+_Labels_ are key/value pairs. Valid label keys have two segments: an optional prefix and name, separated by a slash (`/`). The name segment is required and must be 63 characters or less, beginning and ending with an alphanumeric character (`[a-z0-9A-Z]`) with dashes (`-`), underscores (`_`), dots (`.`), and alphanumerics between. The prefix is optional. If specified, the prefix must be a DNS subdomain: a series of DNS labels separated by dots (`.`), not longer than 253 characters in total, followed by a slash (`/`).
+
+If the prefix is omitted, the label Key is presumed to be private to the user. Automated system components (e.g. `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, or other third-party automation) which add labels to end-user objects must specify a prefix.
+
+The `kubernetes.io/` and `k8s.io/` prefixes are reserved for Kubernetes core components.
 
 Valid label values must be 63 characters or less and must be empty or begin and end with an alphanumeric character (`[a-z0-9A-Z]`) with dashes (`-`), underscores (`_`), dots (`.`), and alphanumerics between.
 
@@ -61,12 +64,12 @@ Via a _label selector_, the client/user can identify a set of objects. The label
 The API currently supports two types of selectors: _equality-based_ and _set-based_.
 A label selector can be made of multiple _requirements_ which are comma-separated. In the case of multiple requirements, all must be satisfied so the comma separator acts as a logical _AND_ (`&&`) operator.
 
-An empty label selector (that is, one with zero requirements) selects every object in the collection.
-
-A null label selector (which is only possible for optional selector fields) selects no objects.
+The semantics of empty or non-specified selectors are dependent on the context,
+and API types that use selectors should document the validity and meaning of
+them.
 
 {{< note >}}
-The label selectors of two controllers must not overlap within a namespace, otherwise they will fight with each other.
+For some API types, such as ReplicaSets, the label selectors of two instances must not overlap within a namespace, or the controller can see that as conflicting instructions and fail to determine how many replicas should be present.
 {{< /note >}}
 
 ### _Equality-based_ requirement