Well one of this things that becomes apparent in this conversation as well as the other current thread on a similar subject is that there a lot of opinions on how Rhino works and should be used, as well as some definite misconceptions. There are those that say “always do this!” and others that will say exactly the opposite, “never do that!”…
What is true is that Rhino is not necessarily designed with a lot of “safeguards” (limitations) that might be built into a solid modeler to keep the users from having open objects. This is because Rhino does not favor “solid” modeling over “surface” modeling; instead it favors the ultimate flexibility in creating any kind of object, at the expense of creating a number of “challenges” for users who are not familiar with how it works. jim called Rhino a “minefield” in the other thread, and while I wouldn’t go that far, there are definitely some traps for the unsuspecting…
As far as Boolean operations go, it is vitally to important to understand how they work - some info is on this page as posted above. As others have said, they are nothing more than automations of Intersect/Split/DecideWhatToDelete/JoinTheRest. As it doesn’t show you the manual parts in between, it won’t show you where it’s failing, and thus you won’t know how to fix what’s wrong.
That’s why you do need to know the manual process behind Booleans, so that you can get in there and fix things if necessary. There are people who say “never use Boolean operations in Rhino”. I do not personally favor this blanket approach to things. Many experienced users run Boolean operations every day without problems. But you do need to know how to react when they go wrong, otherwise you will be infinitely frustrated.
–Mitch