"Client-shared state" = state in the content process that's shared by multiple JS interfaces (e.g. two GPUBuffer interfaces on different threads pointing to the same buffer object).

Recently I've been working on detangling the client (content timeline) and service (device timeline) states in the spec. Part of this was #3014 which led to the realization that (I think) there is actually no client-shared state required in GPUBuffer for mapping state like I had thought there was.

I believe this leaves .label as the last piece of potentially client-shared state when we add multithreading. Here are the options I see for it:

1. Label is internally-synchronized client-shared state, can be racily used across threads. Also creates a high precision timer, but we probably already have that.
2. Labels are per-interface, not per-device-timeline-object, and we somehow send down the label with every call individually or something.
3. The string you get from .label is the last label set from this interface and may be incorrect if e.g. another thread set it since then.
4. Just change .label to .setLabel() so you can't read back the label. Users have to store the label off themselves if they want the behavior of option 1 or 3. Unlike the others, this one is a pre-V1 change.

I'm in favor of option 4.