To begin with, I would like to note that the tool in question (the one that takes FX shader as an input and produces OGRE material as an output) is far from being a "streamlined" exporter - i.e. right now it is more an option to save time for a person who can smooth out the problems after the tool did its job - and it is at least a starting point for those situations when there is only .fx source available, so its hard to speak about "compatibility with OGRE fx export tool".
The tool itself contains the homegrown parser of FX which I wrote using only the scarce BNF available from Microsoft.
SAS support within the tool is non-existant, actually I was looking at the recent XNA offering as a way to replace FX parser code completely, so you can see what stage it is at - better than nothing, but far away from what everyone wants
.As sinbad said, in many ways OGRE materials are different from FX. In many cases this is a subtle semantical difference which cannot even be handled at FX=>Ogre exporter level (i.e. at FX level I don't know what kind of orientation the model on which the shader was applied was using - lhs, rhs? where should normals point, etc.). This is also true for RenderMonkey exporter which I did.
Basically, the best way to support OGRE (IMO) is to provide OGRE material generator at the place where the most information is available rather than use a chain of formats where details are leaking (i.e. ShaderFX => FX => OGRE is inferior compared to ShaderFX => FX + OGRE). OGRE material can be provided as an option at the export time - if you guys are willing to do this kind of integration, it is the best approach IMO - otherwise it is rather a question of fxogretool's maturity rather than ShaderFX's compliance with it (except basic instructions and variable layout which sinbad mentioned).
