NB: the link seems to have been typoed, the correct link is most likely https://github.com/felix-lang/felix

Can you please explain
"I would use it to get programmable constructions as plugins into an runnig solvespace application."
Maybe an example?

I would like to describe the construction of the solvespace objects programatical like OpenSCAD is doing it. But instead of developing an domain specific language (DSL) use an already powerful language which is expressive by itself, like Haskell.
How could it look like?
We write a description for our model:
mod = do
a <- point 0 0 ; point a initially at 0,0
b <- point 1 1 ; point b initially at 1,1
l1 <- line a b ; line l1 from point a to point b
c <- point -1 0 ; point c initially at -1,0
d <- point 0 1 ; point d initially at 0,1
l2 <- line c d ; line l2 from point c to point d
l1 || l2 ; l1 should be parallel to l2
move c ; point c can move
length l1 0.5 ; length of l1 should be 0.5

this is like haskell pseudo code.. we compile it and the result will be pushed
to solvespace (which reads the plugin with dlopen and runs it).
Now the two lines should be visible.
Reaplying the code should not generate a new model but instead only changes
should be applied (thus maybe change the length of line l2)
How interactions with the normal user interface of solvespace could happen is still open for me.
One helpfull navigation would be to highlight the parts in the source if an entity is clicked in the GUI.
Easier would be to propagate the identifiers as decorations to the model.

Of course I've tryed FreeCAD and their Python integration but I found it not very usefull and user friendly. I would favour a statically typed language over a dynamic one.

I apreciate your thoughts on this..

Unfortunately the core of SolveSpace is not designed to be driven programmatically (if you violate a precondition it just asserts, killing the process), so it is not currently viable to add such an integration with any language, Felix or other.

You're of course free to do so in your own fork, but an integration that requires knowing exactly which preconditions must not be violated in order to be useful is not something I think should be upstream.