As the purpose of the roadmap seems to be guiding future development, the
list of editing operations that rely on the chromaticities of the RGB
working space needs to be expanded. The following list is not complete, but
it's a start:

It's OK with me if you put the information in the GIMP wiki. But if you
attribute the information to me, please include the disclaimer that I
think your architecture will eventually collapse under its own weight.

Someone should check all editing operations for perceptually encoded RGB to
figure out which operations depend on the chromaticities, and then add these
operations to the list of operations that need to be special-cased in the
planned "sRGB as PCS" architecture.

The per-op working pixel representation are part of GEGLs design, thus
it isn't really special casing - but specifying.

You designed an architecture around converting images to unbounded sRGB
for editing.

After 6 months of trying to show you that your architecture has serious
built-in problems, you finally believe me, or at least you believe
Mansencal and Sayre. But you want to keep the architecture anyway.

So now all chromaticity-dependent editing operations will require a
brand new "special "specifying"", unless the image is already an sRGB image.

If you didn't intend to convert all images to unbounded sRGB for
editing, there wouldn't be any reason to "special "specify"" roughly
half of all the editing operations that you offer through the GIMP UI.