Looks like you've found a bug, Dinasset.
The problem is actually in the decompose plugin, not recompose.
The decompose plugin attaches a Gimp "parasite" (ie. a data block containing text information) to the decomposed image, bearing the information necessary for recompose to do the re-composing automatically.
Unfortunately, the "compose_type" strings for the YCbCr *256 modes have been mis-specified in the definition table, without underscores between the various parts of the name ("YCbCr ITU R470 256" instead of "YCbCr_ITU_R470_256"):
{ "YCbCr_ITU_R470", TRUE, 3, { N_("luma-y470"),
N_("blueness-cb470"),
N_("redness-cr470") }, extract_ycbcr470 },
{ "YCbCr_ITU_R709", TRUE, 3, { N_("luma-y709"),
N_("blueness-cb709"),
N_("redness-cr709") }, extract_ycbcr709 },
{ "YCbCr ITU R470 256", TRUE, 3, { N_("luma-y470f"),
N_("blueness-cb470f"),
N_("redness-cr470f") }, extract_ycbcr470f },
{ "YCbCr ITU R709 256", TRUE, 3, { N_("luma-y709f"),
N_("blueness-cb709f"),
N_("redness-cr709f") }, extract_ycbcr709f }
and so the recompose plugin gets confused when it tries to interpret the parasite.
You can see the difference on the Script-Fu Console:
> (gimp-image-list)
(2 #(7 1))
> (gimp-image-get-parasite 7 "decompose-data")
(("decompose-data" 0 "source=2 type=YCbCr_ITU_R470 22 23 24 "))
> (gimp-image-list)
(3 #(8 7 1))
> (gimp-image-get-parasite 8 "decompose-data")
(("decompose-data" 0 "source=2 type=YCbCr ITU R470 256 26 27 28 "))
If you are writing a script to do your inverting, you could (in theory) actually "mend" the parasite from your script (eg. change "YCbCr ITU R470 256" to "YCbCr_ITU_R470_256").