It is all related to the native calling convention. In your first test you hadn't registered the Integer class correctly, which is why you were getting the wrong result. The original declaration should be registered with the flags asOBJ_APP_CLASS_C, not asOBJ_APP_CLASS_CK as it didn't have an explicit copy constructor.
When you explicitly declared the copy constructor in the Integer class the result was corrected as now the flag asOBJ_APP_CLASS_CK was correct.
If you're using a compiler with support for C++11 features (e.g. gnuc 4.7+, or MSVC 2012+), you can use the helper function GetTypeTraits<T>() to automatically determine the correct flags. For example:
#include <add_on/scripthelper/scripthelper.h> r = _engine->RegisterObjectType("Integer", sizeof(Integer), asOBJ_VALUE | asOBJ_POD | GetTypeTraits<Integer>()); assert(r >= 0);
As for AngelScript calling or not calling the copy constructor, that is an optimization thing. There are still some places in the library where AngelScript will first create the object with the default constructor and then assign the value with the opAssign method. These are already on my to-do list to improve so that the copy constructor is called directly.
The btVector3 type has another trait that is not yet supported by AngelScript, and that is that the type is 16byte aligned (to optimize it for SIMD instructions). As such you cannot register this type as a value type. If you really want to use btVector3 directly in the scripts you need to register it as a scoped reference type, which will behave as a value type in the script, but is really allocated on the heap where it can be properly aligned to 16byte boundaries. Combine that with a memory pool for the allocation and deallocation of the vectors and you should not have any noticeable performance impacts.
Another option is that you avoid exposing the btVector3 type directly to the script, and instead use an ordinary unaligned structure for the vector3 type that the script will use. Of course, you will need to create wrappers for the functions that expect the btVector3 type, but hopefully you don't have too many of those exposed to the scripts.