It doesn’t count the WorldXY/WorldXZ/WorldYZ planes for the intersection.
GH.PlaneRegion.gh (11.9 KB)
According to my understanding of what the command should do, the correct result should be only Quadrant I (X+,Y+) region.
You should place your region plane origin inside your desired region.
1 Like
It is placed inside, Planes do not have boundaries, it should be considered by the intersection even if its origin is miles away.
Unless it tries to create a boundary outwards with the infinities, which would also be considered a bug.
What Kim said was put it inside the desired region (which has boundaries)
in your definition, the base plane was in the edge of it. moving it a little to the right and up, makes it work ok.
(BTW, this must be a bug… one would expect it to work irrelevantly from position)
plane.gh (8.6 KB)
I understood very well what he said, but shouldn’t be like that, since in case of only one enclosed “domain” object, there’s only one solution, it should not matter where the origin of that plane is located.
I’m with you on that.
Maybe it is like this for more complex situations where more than one regions are formed, so as to chose which one to keep.
1 Like
I assumed they wanted to make one region overall. That’s why I created the second case. Perhaps someone from McNeel could clarify better what they wanted to do.
In this image for example, the intersections of just 4 planes create 3 regions.
how should GH know which one to return?
More like 6 regions, 
There should be additional input to cycle through the results.
Update:
or Boolean True=only where the origin is, False=Show all possible regions
actually your comment is smarter than you think.
There are indeed 6 enclosed areas but only one that has all 4 planes as boundaries (without self-intersection)
so my assumption was probably wrong.
maybe it is a bug after all.
Fair enough 
