I can confirm this bug affects every version of 2.8, including the official release. I tested every build I had on hand all the way back to Blender 2.8 Hash: 388ff003e28b (v 2.80.48), and they all behave the same. The only version of Blender where this bug does not exist is 2.79.6.

Adding a solidify modifier at the top of the stack and un-checking "only rim" appears to cause the boolean operation to behave as normal. This could be a temporary workaround, but reveals that the Boolean Difference operation CANNOT presently work on objects without thickness (ie. a 2D plane).

Current Booleans indeed cannot reliably work on open geometry. We would have to wait for the new Boolean implementation, which is supposedly not that long.

Actually, I think the upper example you marked in red (not working), is the one I would judge "working" -- and the other ones failing...

Yes booleans are on the list of things to rewrite.
There is a long list of stuff that fails, see T47030: BMesh booleans (track todo's)

Pretty sure this is a duplicate [will assume it is T61845, but it could be others of the list as well...]

I could add to the list an example where object transform will make it fail [apply rotation in the following file to see a difference]

Lets hope for the work of @Howard Trickey (howardt) to release us from the pain soonish :)

Thanks Philipp. Well, since the difference operation is supposed to be "subtract" (ie. cutting a hole), the 1st example which "combines" the geometry together is incorrect, while the other two examples work as expected. But as mentioned, this error only occurs when the object being acted upon has no thickness. So yes, it is definitely a strange bug and I hope the super-smart Blender devs will discover the root cause of this... :-) And wow, I didn't even know about that bug when applying rotation. That makes absolutely no sense. You'll notice that it switches to the same incorrect "combine" mode after the geometry is applied, so no doubt the two bugs are somehow related...

In T71524#810103, @Stanislav Blinov (radcapricorn) wrote:

Current Booleans indeed cannot reliably work on open geometry. We would have to wait for the new Boolean implementation, which is supposedly not that long.

Thanks Stanislav. I will look forward to that fix... :-)

Boolean operations are intended to be interpreted as if they are operating on 3d volumes. So, e.g., difference A-B (for objects A and B) means everything inside the volume of A, but excluding any point that is also in volume B. The currently implemented BMesh Boolean code assumes that the two objects are closed volumes -- that is, there are faces all around that are tightly sealed together and you can clearly figure out what is inside and what is outside the volume implied by those faces connected faces.

The example here doesn't have that property, so technically this is not a bug. The code tests inside vs outside by shooting a ray in an arbitrary direction and counting how many faces of the other object it encounters. This is guaranteed to work in the watertight-closed-faces situation I just described, but not otherwise. But it might accidentally work sometimes, which is why you are finding situations where it seems to work and others where it doesn't.

The old Carve solver handled some non-closed-face cases, though I don't know in detail for which cases it was guaranteed to work. I believe it worked when one object was a plane and the other object was a closed object, for instance.

The code I am writing right now (it is getting very close to working -- works on a number of cases already) is using another method to test inside vs outside: something called the "generalized winding number". This is more expensive to calculate (so I may have to make it optional, and use faster ray shooting if the user wants), but it allows non-closed objects to be roughly considered as having insides and outsides. I think it might handle the case in your example, but am not sure yet.

@Howard Trickey (howardt) Thanks so much, Howard, for that detailed explanation and clarification! I look forward to seeing the advanced solutions you are creating.

For me, I'd like to be able to achieve a cut like #1 (top) in my example BUT one that behaves like #3 (bottom) (ie. have a Boolean modifier cut a hole in a 2D plane, but then ALSO be able to Solidify that plane ONLY along its rim and the rim of any cut holes using the Solidify modifier [at the bottom of the modifier stack with "Fill Rim" and "Only Rim" selected]. This way the plane is only "thick" at the cut and does not have backfaces anywhere else, thus saving on wasted geometry for later import into a game engine).

Thank you again for all your hard work!

-Adam