Usually when you talk about a geometric kernel in the past three decades, you're talking mainly about, but not exclusively about, a solid modeler.
A solid modeler generally consists of a trimmed curve and surface library with lots of topological reasoning, to be able to represent closed regions of space and manipulate them by adding holes and rounding features and offsets. The idea is to be able to represent and operate on just about any 3d shape imaginable. Solid modelers of recent years have had support for nurbs surfaces and polygonal subdivision surfaces, but also include support for conic sections, beziers and other implicit or parametric curves or surfaces. Many of them, like OpenCascade are arranged in a logical object oriented fashion which abstracts the complexity. They have to be general, featureful and fast for anybody to want to use them. It's a whole heck or a lot of math and geometric reasoning (and debugging) which makes them valuable (and huge), and although you might want to talk about a "new" kernel you would never just want to chuck something like OpenCascade and start over. OpenCascade, ACIS, Parasolid, SMLib and others encapsulate a huge corpus of knowledge no matter what language they are written in. I have taken criticism from other Lisp hackers for writing Lisp bindings to OpenCascade instead of "starting over" in Lisp, but these people really have no idea what they are talking about.
Interesting. Sounds like a non-trivial undertaking. Both writing an interface or starting a new design. Either way, I would be happy if our system develops along to the point that serious engineering packages would want to use it.
