Yes, different types of film react depending on their different “sensitivity” to colors
(easy to see when using Nik 7 SilfverEfex & choosing different black and white films.)
The irregularity is the additional white point shift when adding a red filter from FP plugin in PL8 … (see above).
DxO should be able to figure that out. 
@Joanna I apologise for this slightly off topic post.
@Wlodek uploading the image to a cloud service is one option, that I tend to avoid.
An alternative is to use 7zip (free and available on Windows and Mac) to split the RAW file but the bits cannot be included in one zip file because they would be too big as well!!
So zip each part and upload to the forum
P1137557.RW2.001.zip (9.6 MB)
P1137557.RW2.002.zip (9.7 MB)
P1137557.RW2.003.zip (3.1 MB)
P1137557.RW2.dop (9.9 KB)
Anyone who is wants to use the image can then download the zips, unzip the parts and use 7Zip to reconstruct the original file.
For your large images it only needs to be split in two I believe.
Slightly messy but it gets the job done.
With further experimentation, I’m finding that using the channel mixer (e.g., darkening blue to affect the sky) is also misbehaving sometimes with WCS=wide (if certain B&W emulations are selected) and even affecting how the filter palette adjustments behave (e.g., a red filter now lightens the sky). This is with a JPEG from a phone camera. I will pass my observations along to support.
A thought, Joanna: when using the Wide Gamut CS do you have Soft Proofing set ON ?
If I am printing, yes. But that makes no difference to the behaviour of the red filter lightening the blue areas above around 112, instead of continuing to darken them like the legacy colour space does.
Red filter at 200:
Legacy CS…
WGCS…
Just an update to let you know that I still haven’t even had an acknowledgement to this report 
Further update. I have finally received a message stating that they have been able to replicate the issue but, in essence, it lies somewhere in the depths of the colour processing pipeline where touching one thing could break a whole lot more
No plans for an immediate fix but it looks like it will be added to the ever growing todo list.
Well, at least there’s a workaround while we await the release of PL100 
I fear that problem is at the root of most of the problems with PL.
Did DxO provide some details, or was it careful wording only?
What exactly they were able to reproduce?
I can only describe it as DxO standard 
I gather the problem that I reported 
OK, sorry for the question with an obvious answer. Somehow I got diverted by my Channel Mixer experience but it’s all about the Filter tool.
I’ve also received a response from DxO. They confirm that the problems particularly arise “when processing combinations of black-and-white renderings, channel mixer adjustments, and color filters.” Yeah, the rendering pipeline is complex and its algorithms need a “fundamental overhaul” for all the parts to work in harmony correctly (and, I’m guessing, for various adjustments to not have to be altered to produce the same results they do now).
