No. SolveSpace's internal modeling functions assume that they are always called with correct arguments. If this is not the case, the entire application (or anything that embeds SolveSpace) will abort.

This does not apply to the constraint library because it is carefully designed to avoid this problem--although error reporting is almost entirely missing, the amount of invariants is far smaller and this is a tractable problem.

Doing what you want such that it is actually usable would require a complete restructure of the entire application.

Can it be possible in the future version?
Infact, I opened this issue as a Feature Request.

I see mixed manual and programmed modelling
as the logical direction for the evolution of CAD systems.

This is an obvious improvement, but there are two issues.

1. It would only become possible after there is a Python API (because there are more constraints--SolveSpace's API would have to play nice in other applications, as opposed to playing nice with itself).
2. This is an enormous amount of work. Likely more than a full rewrite from scratch.

As there is no one at the moment who can invest several person-years of work into refactoring SolveSpace, you should not expect this to happen any time soon.

I did NOT request a Python API. It was just an example.
c++ is fine.

Besides, if anything which plays nice with outside c++ code exist,
then it will become trivial to build any wrapper around it.

I did NOT request a Python API. It was just an example.

A Python or Lua API is something that has long been planned.

A Python or Lua API is something that has long been planned.

I'd appreciate it. However, I'd personally avoid an additional
runtime in between. I think, layered approach would be better.
That is exposing C++ first.

After that, providing python, Lua, whatever... layer becomes trivial.

Unfortunately, converting a standalone C++ application into an usable embeddable library is a task far more complex than the already extremely complex task of adding error handling to external APIs. As such I do not see it as a priority.

Unfortunately, converting a standalone C++ application into an usable
embeddable library is a task far more complex than the already extremely
complex task of adding error handling to external APIs. As such I do not see
it as a priority.

That's understandable. But I'd love to see this issue as "Open"
even with a low priority.

As I currently see it, there's essentially no chance this will happen. There's no point in making the issue tracker a wishlist of items that will not happen.