As far as I can make out this is a SWIG bug. Someone else has already reported it in fact. Fortunately there's a simple, reliable workaround via PHP's class_alias:
%module test
%{
#include "test.h"
%}
%pragma(php) code="
# This code is inserted as a workaround for template bugs with SWIG
class_alias('IntVec', 'myvectorT_int_t');
"
%include "test.h"
%template(IntVec) myvector<int>;
The pragma here inserts the code to setup the alias at the start of the generated PHP file.
(There's another possible work around too - rather than using public member variables access via getter/setter functions works as expected)
The bug report also mentions another possible workaround although I'm not keen on that since it requires using a rather ugly name for the template type.
Justification for bug assumption
The code for __get includes:
$c=substr(get_resource_type($r), (strpos(get_resource_type($r), '__') ? strpos(get_resource_type($r), '__') + 2 : 3));
                        return new $c($r);
When you get here $c is set to myvectorT_int_t which would be correct except for the %template directive.
When we add a myvector<int> get() function to S the generated code results in:
 $c=substr(get_resource_type($r), (strpos(get_resource_type($r), '__') ? strpos(get_resource_type($r), '__') + 2 : 3));
 if (!class_exists($c)) {
     return new IntVec($r);
 }
 return new $c($r);
which crucially includes the generic code that would be correct without the %template and as special check to see if it's actually an IntVec.
There's also a comment in the Source/Modules/php.cxx:
// FIXME: Currently we always use call_user_func for __get, so we can
// check and wrap the result.  This is needless if all the properties
// are primitive types.  Also this doesn't handle all the cases which
// a method returning an object does.
Finally the code generated by the same interface file for Java is correct.