First the FMX_StartScript function is not implemented for FileMaker Server. The environment is missing there to have it run. FMX_SetToCurrentEnv is also not working on the Server as it can't create sessions. And as session details are not available, the server can't do anything here. If you use idle function, well it is also not called on the server all the time, only if a script is paused.
The FixPtAutoPtr class can hold numbers of 100+ digits length. But default precision is only 18 digits and there is no native way to assign or query Int64 or UInt64 values. One work around can be to use AssignDouble and AsFloat which has problems with precision. Another work around is to use text functions and convert to/from number in C code. For MBS plugin we prefer to do math and calculate if a big number needs to be returned. e.g. UpperPart * Factor + LowerPart. So number is split in two parts and we multiply the upper part and add it together. That allows to build a 64bit number in 32 bit without loosing precision by going through double.
Be aware that FileMaker always uses UTF16 internally to store texts. For converting to/from wchar_t on Mac OS X you need to do the UTF32 transcoding. In MBS Plugin we have code for this, so our UTF32 aware text functions can probably handle special characters like smileys.
Getting UTF8, Mac or Windows encoded text from a fmx::Text has a challenge: null bytes. Most functions simply ignore them and cut the string on the first null character. But some functions in our MBS Plugin actually handle this special case correct.
When your plugin receives kFMXT_Init call and you call your plugin init function, be sure to save version and application values in global variables. This way you can use conditions everywhere in the plugin like "if (gFMVersion >= k150ExtnVersion)" or "if (gFMApplication == kFMXT_Pro)". This is important as our plugin supports version from 8.5 to 14.
On FileMaker Server scripts may run in parallel. Be sure your plugin is prepared for that by locking global data with mutex. While you can't currently get the session ID easily, you can of course check current thread ID by OS functions to see if two calls are on the same thread.