Interesting thing:

1) It should happen at all because using $this->B should result in an implicitly declared proeprty.

2) It is expected behavior because __get/__set have a simple recursion protection which disables __get/__set during __get/__set calls.

Another exaple, where IMHO it should work:
<?php
class Creator {
    public $objects;
    
    public function __get($name) {
        if (!isset($this->objects[$name])) {
            $this->objects[$name] = new $name($this);
        }
        return $this->objects[$name];
    }
    
}

class Class1 {
    public function __construct($Creat) {
        echo 'Class1';
        $Creat->Class2;
    }    
}

class Class2 {
    public function __construct($Creat) {
        echo 'Class2';
    }    
}

$Creat = new Creator;
$Creat->Class1;
?>

OUTPUT:
Class1
Notice: Undefined property: Creator::$Class2 in D:\Server\www\noname\test.php on line 17

Expected:
Class1Class2

I really doubt that it's a bug because if we allow calling __get() from __get() you'll get into endless loop easily, which is of course much worse than just a notice.
Take a look into zend_std_read_property() (in zend_object_handlers.c), there is simple loop protection.
So I'd prefer more to see this documented than fixed in some way.

Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php

__get is not recursive - i.e., fetches happening in __get would not invoke __get again for the same object. Indeed, this is loop protection and also feature allowing __get to access/create properties that other methods would use __get for.