Change:
4.2. <del> Dynamically generated names can be used to track users if used too often.  Conversely, registering too many names will also generate useless processing.  The proposed rule is to create and register a new generated name for a given IP address on a per execution context. </del> <ins> It is important that use of registered mDNS hostnames is limited in time and/or scope.  Indefinitely reusing the same mDNS hostname candidate would provide applications an even more reliable tracking mechanism than the private IP addresses that this specification is designed to hide.  The use of registered mDNS hostnames SHOULD be scoped by origin, and have the lifetime of the page. If the generated mDNS hostname candidate does not follow the pattern described, the exposed candidate might be used for fingerprinting. If there are multiple host candidates with different IP addresses, IPv4 and/or IPv6, each results in a separate mDNS hostname candidate. The number of mDNS hostname candidates can provide a fingerprinting dimension.  If so desired an ICE agent MAY expose additional mDNS hostname candidates that are not registered. </ins> 4.3.

Discussion:
NAME I tried to address your comments without splitting the procedure. Splitting the procedure makes a bit awkward to handle the error case and the mDNS registration is then only two steps really. Let me know what you think.
We found Microsoft recommended using “.local.” as a pseudo-TLD for small private networks with internal DNS servers (here is an article that is still accessible, URL(v=ws.10), and the Wiki page URL covers some legacy recommendations made by Microsoft, though some I think have been removed). We also note that Apple provided guidance on how to configure OS X to look up “.local” hostnames using both mDNS and DNS (URL, I am not sure if this is still the case for newer OS X). Hostnames containing only one level (label) in addition to “.local” are resolved using mDNS by default. Names containing two or more labels in addition to local will be resolved using DNS by default. For this reason, our current implementation only generates names containing one additional label (also recommended by RFC 6762 I think). I understand this section is more about the principle, but I am wondering how we/or if we should define failure here. Since we use the random UUID for hostnames, name conflicts are likely avoided with minimum retries.
I agree the exposed unique name should end with '.local' which is what step 7 is doing. It is fine to append '.local' in step 4 if that makes things clearer. As of 5, if registering the unique name fails to name conflicts, the issue is that we might detect that conflict after exposing the candidate. An implementation is probably free to decide to wait so as to ensure that there is no name conflict but there is no such guarantee.
NAME do you think we should have a stronger statement about UUIDs requirements. Would something like the following fix the first part of the issue: Step 3 of section 3.1: Generate a random unique name. The unique name SHOULD be a version 4 UUID as defined in [RFC4122].
As of the second issue about the error case, there might be cases where there will be an error case right away. Maybe no interface with simulcast support for instance.
The "should"-level requirement of "URL" sounds good to me.

Do you think if it would be helpful to also refer to Section 3 in RFC6762? The second last paragraph there has a related discussion, and the above requirement conforms to that.
The blocking issue in the security consideration section may also be an example of failure here. I feel we may need to clarify the handling of failure (with limit of retries, for example).
This LGTM with the changes noted below.