I am using the C++ SDK to develop a custom reprojector, and have run into seemingly anomalous behaviour; I hope this is the best place to ask about it. 

Generally the reprojector has worked well thus far on points, polygon, arcs, raster etc.  
However, when reprojecting solid CAD objects (type IFMEExtrusion) I've had to implement the member functions of the IFMEReprojectEngine as follows: 

• As Forwards Projector: 

virtual FME_MsgNum reprojectArray (FME_Real64 *xCoords, FME_Real64 *yCoords, FME_Real64 *zCoords, FME_UInt32 numCoords)=0  //Reprojects the given arrays in place. The zCoords array is optional. If successful, this method returns FME_SUCCESS, otherwise it returns FME_FAILURE. 

• As Inverse/Backwards Projector: 

virtual FME_MsgNum reprojectArray (FME_Real64 *xyzCoords, FME_UInt32 numTuples)=0 //Reprojects the given array in place.  If successful, this method returns FME_SUCCESS, otherwise it returns FME_FAILURE. 

Raster reprojection requires an inverse in order to project forwards; also it would appear that extruded CAD solids do too.  When it is run on raster then 2 projectors are instantiated and the inverse flag is set on one - however the issue here is that the behaviour seems inconsistent for solids: it does not call a new reprojector with inverse set to true, rather it uses the overloaded alternative function which is not documented as an inverse. The worry is that it's not clear if this function is ever used for the forwards case too. 

The question therefore: Is it safe for me to implement the second overload of the member function 'reprojectArray' for the inverse projection?