setClip doesn't work as expected in PDFGraphics2D and PSGraphics2D because PDF and PS cannot set the clipping path, just restric it.
However, a classical java pattern involving the clipping path is to save it, set it and set it back to its initial value:
Shape saved = g.getClip();
g.setClip(newShape);
...

g.setClip(saved);

You could track that behavior from the graphics by generating a class derived from Area in getClip and issuing a gsave after a getClip followed by a setClip so that you could issue a grestore is that clip path is restored.

Otherwise, I would advise you to just ignore the clips (as an option), otherwise, one clip used while drawing using a EPS/SVG graphics will just erase what follows.

Actually, I did manage clips in a similar way in Agile2D, an implementation of Graphics2D based on OpenGL (agile2d.sourceforge.net) because it is very convenient in term of shape transforms.
I keep the clip path as an area in page coordinates to avoid transforming it all the time. However, getClip returns the path in transformed coordinates so it has to be transformed once. When it is restored later, it has to be re-transformed back, which causes rounding errors and computation time.

Instead, you could create a savedShape object for your graphics that would contain the area not transformed, the current transform, and a null transformed area that could be computed on the fly if needed.
When restoring the clip path, the original area would be there if the transforms inside the savedShape and the graphics match.

Don't hesitate to ask details if I am not clear, I'd be happy to help.

Thanks for that project.

Jean-Daniel.