The spec so far seems to derive appeal and simplicity from thinking of a contentHint as an inherent property of the track. A "music" track; a "motion" video; invariant and ever-present.

But it's not. In three respects:

1. A contentHint is potentially a runtime knob. The JavaScript can modify it at any time, yet it's not specified anywhere what should happen then, or when observable effects may be expected, if any.
2. Unlike the data it purports to describe, a contentHint doesn't survive replication through sink->source pipes like a peer connection, element.captureStream(), web audio, MediaRecorder, or even track.clone(). Or does somehow it? The spec doesn't specify.
3. The hint may be wrong. User agents may (someday) detect speech vs. music at run-time. Are they allowed to ignore the contentHint outright? If they ignore it, what happens to observable (testable) effects/settings?

How should browsers behave if the JS twiddles the bit live over time?
How does it work with track.clone()? Can each clone have its own value?
Is JS expected to tack these hints back on like post-it notes that keep falling off?

In the end, I realize this may be up to individual specs using contentHints, but I would expect guidance to be given in this spec to ensure consistency.