This is would also resolve #463 if you used the ignore key instead

They are different. Marks must be considered for bbox calculation and intersection (?), debug shapes not. Although, this is not yet implemented in this PR.

I don't think marks should be considered for intersections and would they be big enough to really count towards a bounding box?

Besides that, if we do have separate keys for debug, marks, hidden and ignore, would there be a way to combine them into one field? Maybe a "type" or "class" key that holds "debug" or "mark", it could even be an array to hold multiple if needed. It could even be a bytefield...
We'll be needing something similar for modifiers anyway.

I don't think marks should be considered for intersections and would they be big enough to really count towards a bounding box?

Besides that, if we do have separate keys for debug, marks, hidden and ignore, would there be a way to combine them into one field? Maybe a "type" or "class" key that holds "debug" or "mark", it could even be an array to hold multiple if needed. It could even be a bytefield... We'll be needing something similar for modifiers anyway.

Yes, I think some kind of "class" is good. We could then provide a function for filtering out certain elements.
Maybe just a tags list of strings/ints?

If we are still aiming for modifiers in 0.3.0, can this be blocked until modifiers are implemented? Then we can use whatever system works for modifiers.

If we are still aiming for modifiers in 0.3.0, can this be blocked until modifiers are implemented? Then we can use whatever system works for modifiers.

Yes. Although path-replacing modifiers need no special handling, as they just replace the original path.