Standard version: 2.0
There is little to no information about the colour space (tone curve and RGB chromaticities) in which image sample values are to be interpreted.
Historically there has been some assumption that the tone curve is probably linear, with a nominal black point at 0.0 and nominal white point at 1.0, but this is not specified and is often not the case.
Depending on the host, unmodified images presented to plugins may be linear, or "video" (typically Rec.1886, or a simple gamma curve), or "log" (e.g. Cineon log, or a modern log curve such as ARRI LogC), or "HDR" (e.g. Rec.2020) or any number of other curves. The primaries may be Rec.1886, or a larger gamut such as Rec.2020 or ARRI WideGamut. Plugins have no way of knowing what the numbers in the image represent. Similarly hosts have no way of knowing in which colour space(s) (if any) a plugin would like its inputs, nor the colour space of its output image.
Some plugins won't care what space the images are in. Some however need to know in order to make sense of the data. A lens flare, for example, needs to behave very differently (a) when the input data is linear with highlights well above 1.0 (b) when the input data is log-like with highlights preserved but much lower in the range, (c) when the input data is in a display-referred colour space where highlights have been rolled off to fit under 1.0.
It may be that some plugins and/or hosts prefer to work with non-RGB primaries, e.g. X'Y'Z'. A mechanism to specify colour spaces could support this.
At first glance I'd suggest