The segfault is because of infinite recursion: if ->foo does not exist then __get(foo) will be called, which tries to do ->foo, which does not exist so __get(foo) will be called... until PHP dies.
__get() should never blindly do a ->$name for this reason. If anything it should manually test for the presence of the property, like with get_object_vars(), before attempting to return it.

If there is a bug here it's because $wpq->interesting =& ret_assoc() does not behave like a regular assignment (given that ret_assoc() isn't returning by-reference), creating the property on $wpq. If you dump $wpq after this line you'll see it doesn't have a $interesting property - just $unreferenced.

Making ret_assoc() return by-ref results in a fatal error "Cannot assign by reference to overloaded object". I too don't think that should be a problem if __set is not implemented and assignment should behave normally (ie, creating the property).

hmm, it's not a stack overflow segfault..

it's a double free, freeing the op1 of ZEND_ASSIGN.

a simple fix could be(but it break some tests, since they are not sharing one zval anymore):

$ git diff
diff --git a/Zend/zend_execute.c b/Zend/zend_execute.c
index ac00c28..0eff680 100644
--- a/Zend/zend_execute.c
+++ b/Zend/zend_execute.c
@@ -896,13 +896,11 @@ static inline zval* zend_assign_to_variable(zval **variable_ptr_ptr, zval *value
 			if (UNEXPECTED(variable_ptr == value)) {
 				return variable_ptr;
 			} else if (EXPECTED(!PZVAL_IS_REF(value))) {
-				Z_ADDREF_P(value);
-				*variable_ptr_ptr = value;
-				ZEND_ASSERT(variable_ptr != &EG(uninitialized_zval));
-				GC_REMOVE_ZVAL_FROM_BUFFER(variable_ptr);
-				zval_dtor(variable_ptr);
-				efree(variable_ptr);
-				return value;
+				ZVAL_COPY_VALUE(&garbage, variable_ptr);
+				ZVAL_COPY_VALUE(variable_ptr, value);
+				zendi_zval_copy_ctor(*variable_ptr);
+				_zval_dtor_func(&garbage ZEND_FILE_LINE_CC);
+				return variable_ptr;
 			} else {
 				goto copy_value;
 			}