So to summarize the situation here, we have the following:

System Metrics

Values for system.cpu.state:

• user
• system
• nice
• idle
• iowait
• interrupt
• steal

Process Metrics

Values for process.cpu.state:

• user
• system
• wait

Container Metrics

Values for container.cpu.state:

• user
• system
• kernel

Based on @braydonk's comment we can change the wait value of the process.cpu.state to idle and hence the process.cpu.state will be a subset of the system.cpu.state. Then we can use the superset for both.

Then the only difference with the container.cpu.state is the kernel value.
Checking the dockerstatsreceiver implementation, this value comes directly from the Docker API. For now I guess we should use it as is unless we find way to properly correlate it with rest of set's values. @jamesmoessis feel free to comment here if you have more information.

My first proposal would be to unify the attribute to cpu.state with possible values being the following [user, system, nice, idle, iowait, interrupt, steal, kernel].

What do you @open-telemetry/semconv-system-approvers think about this?

I like the proposal, it simplifies things.

@lmolkova Can we limit the valid values of an attribute when used in a concrete context to a subset of the overall allowed values through the tooling?

@ChrsMark : Primarily for system metrics, we consider the states mentioned here. IThere's an additional state softirq, which I didn't find in the code you referenced.
Just a thought, if we want to consider that as another member of the state as well.

Removing the triage label, as this sounds like a good plan. Unifying them makes sense to me.

@lmolkova any thoughts on #840 (comment)?

I am in favor of this.

IThere's an additional state softirq, which I didn't find in the code you referenced.

@ishleenk17 I think this is Linux-specific, so it should go into its own separate metric like we did on #323

@ChrsMark it's not possible yet but we are discussinga few weeks ago this option, one similar reference would be open-telemetry/build-tools#192 to exend enum from some base one, but option to use specific fields will be most probably also implemented