Exactly.
I don’t quite understand what all this discussion is about. The increase in Cycles kernel-size (being the root cause for all the issue at hand) would only apply, if spectral rendering was a thing you could just turn on and off in Blender before rendering at will.
Unless I’m missing something here.
But why would anybody need this so badly to justify all the hassle? They could just, as @thinsoldier suggested, provide one rgb cycles build and one spectral cycles build. Problem solved.
In an ideal scenario a user could even install the spectral cycles as an external renderer on top of a blender installation which shipped with rgb cycles. Then one could switch between the two at runtime as you can switch between cycles and eevee or luxcore or whatever.
Though I believe currently cycles is fuzed a bit too tightly with blender internally for this to work.
On the other hand, afaik, there’s work being done on disentangling this more and interfacing cycles via some api, so maybe someday it might work like that.
So this is one of those hysteric BA-discussions again, right?
There is no indication whatsoever Brecht considers to outright reject the patch alltogether because of kernel-size considerations.
Those considerations only apply to the idea of making spectral rendering a runtime option to switch on and off anytime.
greetings, Kologe