I have included version 2 which is still in development but seems to work solid & without issues so far.

I'm concerned about this. The people who maintain SolveSpace (almost exclusively me at the moment) don't have a lot of time and resources to deal with unstable dependencies. Ideally, I would like to merge the extensive backlog of patches (see the patch-available tag on the issue tracker) and publish a 3.0 series of releases, culminating in something that can be considered stable. That has been the plan for a few years. However, I only have a few hours per month that I can spend maintaining SolveSpace at the moment, so adding complex new features is mutually exclusive.

Are there any specific improvements from replacing the existing polygon code that has seen many years of use with an in-development (i.e. unstable) external dependency?

I am planning on adding direct offset support to the editor as well, can you give me some pointers on how I would go about doing this?

Direct offset would be useful, but it cannot work on polygons, since then the offset path could not be constrained against, severely limiting its utility. It should work on entities. Likely, it should be a new group, similar to e.g. "Step and Repeat Translating".

I am planning to use SolveSpace for simple CNC jobs over here, another option I am interested in adding is a drag knife option that adds arcs in all the "turns".

I think adding CAM features, in general, would be greatly beneficial, but it should be done as a part of an overarching design and not a per-case basis. I think it would not be appropriate to implement ad-hoc CAM features benefitting one person's specific workflow as a part of SolveSpace. There is a number of existing projects that can convert vector graphics to G-code while applying specific CAM transformations; because they can focus on CAM exclusively, they can produce much better results than a CAD package with a set of ad-hoc CAM features.

I thought I was using version 2 of ClipperLib but actually I seem to have been using the old one (which is good in this case I guess).

This improves the offsetting mostly because it can handle more complex shapes.

ClipperLib is pretty battle tested, and seems to be the de-facto standard (unfortunately there is not much choice of libraries for this) for offsetting contours in many G-Code editors.

Your other points about direct offsetting and extra CAM features totally make sense.
I will create make a separate tools for this.

I will finish up the work from this PR so I can use this myself at least and for anyone else that might be needing it in the future.

I thought I was using version 2 of ClipperLib but actually I seem to have been using the old one (which is good in this case I guess).

This improves the offsetting mostly because it can handle more complex shapes.

ClipperLib is pretty battle tested, and seems to be the de-facto standard (unfortunately there is not much choice of libraries for this) for offsetting contours in many G-Code editors.

If this only depends on stable ClipperLib and improves the quality of offsetting, then I am entirely in favor of merging this PR.

I took another look and it appears that adding rounding to the turns is a straightforward call into ClipperLib. Is that the case? Then I think we can add it as well, no reason to not expose this feature when it only depends on well-tested ClipperLib code and an UI that invokes it.

I thought SolveSpace could generate offsets when it produces g-code. It's hard to find but it's there. Also, offset curves are important for creating some geometric features. In that case it's best not to do piecewise linear, but actual offset curves if possible. This is an area worth doing more planning before jumping to a solution.

Closing. We need to rework path offsetting in solvespace itself. Also don't want yet another external dependency.