It appears that I made a break-through. As of revision 1435, all tests pass successfully with MinGW32 4.7.0 and 4.6.2.
The MinGW developers made some strange choices with the new ABI. For the most part they seem to have wanted to more closely follow the MS ABI, most likely to make it easier to use the many dlls available, but in some cases they ended up with something that is neither like the MS ABI nor the GNUC ABI. This doesn't make any sense at all to me, and quite frankly I believe they may very well change it again with a future version.
Jake's correct. CreateUninitializedScriptObject only works for script classes, and not for registered types. AngelScript wouldn't know how to safely create an uninitialized instance of a registered type.
The order of the script sections doesn't matter to AngelScript. The only thing that matters is that a script section added to AngelScript only contains fully declared entities, i.e. you cannot declare part of a class or a function one section and the other part in another section.
Sequential pre-processing commands were not on my mind when I implemented the script builder add-on. To support sequential pre-processing commands the includes would probably have to be pre-processed as they are found. This would likely make the add-on more complex.
The token definitions used internally by AngelScript are not exposed to the application, so there is no way to get them without modifying the library. The ParseToken() method can quite easily be modified to return the token definition. What exactly do you want this for?
It's better to define AS_USE_NAMESPACE on the project settings, rather than in the code. Otherwise it is very easy to forget it in some places which makes part of the code refer to AngelScript functions without the namespace, and others with it, which is sure to cause linker errors.
In your case the namespace got declared when you included the scriptstdstring.h, thus the code sees the RegisterStdString() as part of the namespace. On the other hand, when the scriptstdstring.cpp was compiled the namespace was not declared, so RegisterStdString() was implemented outside the namespace.
It's tricky, but can be done similarly to how the property accessors are evaluated already, i.e. the decision to use either set or get needs to be deferred until the very last moment when it can be determined which function signature the delegate is expecting.