The support material in the holes is OK. If you lower pattern spacing to 0.1 it will do what you think, but it will increase time and consumption. It is caused by discretization of the space to squares. If a small part of a square is used for support then whole square is built. Therefore, the hole is filled.

The only solution is to change the algorithm from squared support to an organic one. This is more complicated and computing will take much more time.

The supports on the sides are definitely an algorithm error.

And the one more layer on the top of the interface layer (shown by arrow)?

Looks like it is by purpose. Some kind of fence but don't know what is the purpose. However, it is so small so it does not hurt. Maybe it is used for easier support removal.

And one two more issues with supports. Default profile settings used.

• interface layers in the air (red)
• too small support to be printed/usefull (blue)

Testing snug supports

Fixed with af9c7c9

Implementing a new switch for the shape of support towers:
expanded to a grid (the old way) vs.
snug (like the upstream Slic3r, Cura or Ideamaker).

Snug supports suffered from the degeneracies when merging overhang islands
over a large number of layers when projecting the support towers down.
We borrowed the idea & a bit of code from Cura by simplifying the support
polygons by closing the concave cracks, see the smooth_outward() function
and the MutablePolygon class.