This should be cleared in the documentation. The code returned is valid PHP code, while it won't necessarily run successful.

var_export() assumes a __set_state() exists, but there are cases where it doesn't and there are cases where for different reasons it never can in a sufficient way. Especially for internal classes where we can't export the full state.

For this class, that's not an acceptable position to take.  Consider that I can 
write:

class AdaptorArrayObject extends \ArrayObject {
	public static function __set_state(Array $data) {
		$this->exchangeArray($data);
	}
}

//::then::
//some data that's structured appropriately for ArrayObject state
$oldArrayObjectData = $existingArrayObject->getArrayCopy();

$newArrayObject = AdaptorArrayObject::__set_state($oldArrayObjectData);

You already wrote the functions necessary to implement __set_state()

Why is it on ME to subclass just to call the functions to make this work?  
Functions are written, call them internally and expose __set_state. Easy peasy.

The other SPL data structures are indeed much more complex internally (object 
keys, kv meta data, and value linking), so it makes sense not to offer external 
functions like exchangeArray or getArrayCopy.  But ArrayObject is supposed to be 
much closer to [] is it not? just wrapped in object reference semantics and SPL 
API goodies?

Please reconsider for ArrayObject.

I have fixed the documentation, and change this ticket to feature
request.