Defer bootstrapping errors on buckets to first operation

Foundational RFC:

Also, as outlined in the bootstrapping RFC, the bootstrap process itself is lazy w.r.t error propagation. Errors are deferred into the operation, other than illegal config options on Cluster.connect. This makes sure that the user only has to have error handling in a minimal amount of places.

I am trying to find where this behavior is defined, the Bootstrapping RFC doesn't mention Collections. This is the portion for opening a bucket:

Bucket Connection Sequence
Upon receiving a request from the application to open a bucket for operations, the client must begin the process of opening a bucket connection.
If the cluster object already has a set of connections which are established, the client MUST hijack these connections and perform a SELECT_BUCKET operation against them to upgrade the memcached connections to being bucket connections (rather than cluster connections). Following this hijacking, any periodic configuration fetches being performed at the cluster level must be stopped (since the cluster object no longer owns any connections to perform those requests against).
If the cluster does not own any connections (too early, or another connected bucket already stole them), a new set of connections should be established instead. This should follow the same semantics that are used for a cluster connection with the addition that should all connections to the cluster fail using memcached, the client should revert back to HTTP streaming, as described below.
Once connections are established for the bucket connection, the client should begin refreshing the configuration periodically under the same semantics used above for cluster level connections.

Things come to mind if everything was deferred completely, like how would views work since they are a bucket level construct?