Change:
for incoming Connections, and to which it will attempt to establish connections. <ins> Note that the set of LocalEndpoints returned by Resolve() might or might not contain information about all possible local interfaces; it is valid only for a Rendezvous happening at the same time as the resolution.  Care should be taken in using these values in any other context. </ins> An application that uses Rendezvous() to establish a peer-to-peer connection in the presence of NATs will configure the Preconnection object with at least one a Local Endpoint that supports NAT binding

Discussion:
It feels to me like there's a bit of a gap between how software ought to discover Endpoint Object identifiers for Remote Endpoints versus Local Endpoints. Remote Endpoint identifiers are likely to be defined by the kind of software being used acting on some user input (web browser requesting a page, DNS server recursing, etc.), and these identifiers are resolved through existing internet architecture. Importantly, there's not really any way to check a valid input would work until for a Remote Endpoint. This isn't really true for identifiers on Local Endpoints. While it's true that discovering these things is system-specific, a TAPS API implementation ought to provide a vehicle for discovering what inputs are valid. Two reasons I think it's reasonable to support discovery of local addresses and interfaces include: It'd be unfortunate for TAPS-consuming software to rely on system-specific APIs to implement a UX for configuring that software. Given diversity of public cloud offerings and wide use of multi-cloud deployments, it's reasonable to expect folks to want to dynamically discover what local network addresses and interfaces exist in their environment. If the intent is to not define an API to discover these identifiers, the document should be clarified to discuss what Errors can be returned by and Actions on Local Endpoints. (This is coming from a perspective that "error early, error often" is a best practice, which is admittedly subjective.) If there is agreement to add (for example) and Actions on a Local Endpoint, these should be documented. Further, the and Actions on a Local Endpoint should be described to return an Error when the supplied input would not exist in the results returned by the corresponding call at the time the Action was called. In either case, it would be useful to mention that a successful invocation of a Action is not a guarantee that initiating the precondition will succeed.
This all makes sense to me, and sounds like some things should indeed be added. I'm a little afraid that adding "GetInterface" could cause a rat tail of "GetWhateverElse" ideas... is there a good way to keep that from happening? Something more generic, perhaps - "GetLocalSystemProperties", and explain that such properties could, e.g., contain a list of interfaces?

Regarding early failure, I agree with your suggestions too; note that, even though a Preconnection itself is just a passive data structure (or Object holding data), the call to create it can already fail (some details are in section 3.1 of the implementation draft). I think that's the earliest type of failure that we specify (and since this is an abstract API, I'm not sure if we should start specifying that calls to define an Endpoint (which is where "WithInterface" and such are found) could fail too - the endpoints could just be a 100% passive data structure that's handed over, there might not be any calls involved... so I think it's enough to specify failure of the Preconnection creation).
I think that's a fair concern, and I think a API could work. Two concerns with a single API entry point for Local Endpoint identifier discovery: It provides no means for enumerating interface(s) by address(es) or vice versa without some argument signifying how the caller wants the data returned. It's more likely to cause future API and ABI versioning headaches for implementers when new identifiers are deemed useful for discovery, and require changing the returned data structure. I'm not sure how to effectively allay concerns about adding a billion discovery APIs. I don't think discovery is needed for Transport Properties: I see that as a TAPS API implementer's documentation problem (and consumer's reading-the-documentation problem), and maybe that's worth a sentence of rationale somewhere. I also do not think that a service port discovery API is particularly useful in modern systems (and there are many service discovery protocols to choose from for the cases they are). would then have to reference a yet-to-be-defined local transport concept; since a Local Endpoint is effectively defined by a 3-tuple of interface, address, and port, I think it's unlikely new discovery APIs would be requested / added frequently. Great point! If the system changes between discovery and such that a previously-valid Preconnection is now invalid, the inverse is also possible. Happy to scope this issue only to the point of discovery APIs.
Rendezvous lets you enumerate local endpoint candidates via Preconnection.Resolve(). In general, you shouldn't be enumerating the local endpoints for client-to-server connections, as it will limit the ability to do happy eyeballs, etc.

We can add clarity in the existing rendezvous section to explain that this list could be used for other purposes, but people should be careful.
I'm considering cases like proxies, where interface choice might be important for routing / peering / cost decisions. I agree it's generally not something one would want to do for clients-with-people-behind-them. Thanks for pointing out this is possible with Rendezvous!
I'm trying to write some text to resolve this and as it turns out I'm a bit confused by what Preconnection.Resolve() will return: the set of local and remote endpoints supplied to the preconnection to attempt to rendezvous using; or the set of all potential local endpoints (if none has been specified).