I don’t get your proposal.
What do you think OSL would solve?
I mean, right now if we use OSL to import Material-X then we get non supported shaders for GPU and slower performance.
To export a cycles shader to Material-X you don’t need OSL AFAIK, you just need to compose the node tree as per Material-X specifications, as has been said before, Cycles lacks some nodes compared to Material-X but not so many.
IMHO the proper approach would be to create those lacking nodes to be on pair with Material-X, and I’m sure those nodes will be useful for the user.
Then a 1-to-1 export would be probably possible, and most probably already covered by the addon showed here before.
So I’m not sure where the OSL part comes into play.
What I was proposing was to have a live link to the Material-X files, so the node tree is changed when the Material-X defintion has changed, and the user modifications go OVER that link, so if something changes and cannot be applied a warning can be given to the user, but there is no OSL involved, everything is native Cycles.
Now for other engines, those engines should support Material-X definition, no need to go OSL, specially because it’s CPU limited, and they can be sure to attend the Material-X specifications so in the end all the engines can have the same nodes, and in the end the interpreter for each engine should be done by the engine developers, in the case of LuxCore is the same, the Material-X should be read by the addon and generate the node tree accordingly, is something similar wo what it already does when it reads Cycles material, but it’s something internal, it interprets Cycles nodes and generate Lux nodes internally to pass them to the engine.
The good thing is that if Material-X defintino is taken as a standard, and Lux for example embraces the Material-X definition, then probably it will be capable to interpret Cycles materials without effort, of course there could be specific features that are present in Lux and not in Cycles, but I can imagine that those are more like attributes/variables that can be exported/created accordingly to the needs.
And of course there could be specific nodes that will not be present in the Material-X definition, those could be pushed by the every engine developers I assume, as long as they are generally useful, since Material-X is open source.
And those that are not generally useful will remain as Render engine specific nodes that won’t be possible to export, in the case of Lux those would be specific settings for PGI for example.
In the end, I’m not sure where OSL comes into play