color: define global_remove behavior
wayland/wayland-protocols!14 (comment 2756612)
Toolkit authors are reluctant to handle the global removal, because on most compositors the removal will never happen. OTOH, there is a compositor author who wants to be able to change color-management capabilities at runtime due to dynamically switching renderers.
This new wording strongly suggests the global is never removed to let toolkits avoid all the code that removal tracking would need. Removal is still allowed however. The assumption is that compositors will delay losing their color management capabilities until nothing depends on them. It is up to the compositor's policy to either make that happen or bend the rules.
Note: Bending the rules refers to displaying surfaces' contents "incorrectly", against client expectations. This is already routine, e.g. graying out non-responsive windows.
Clients that do not handle the removal should only ever bind to a
wp_color_manager_v1 global once in their life. Otherwise they risk
confusing the color manager capabilities which may lead to protocol
errors.