@Markiyan Hirnyk: Civilized people do indeed give feedback to answers to their questions, but not even they are capable of doing so when asleep. I live in Denmark where it is at the present moment of writing approximately 8 AM.

But let me hurry with first a thanks for your replies, and then the following piece of feedback to them: Perhaps I misunderstand the output af the full parametric solve, but to me it seems to assign something to a and b, which I do not want, a and b being operators, compare my earlier reply.

@Markiyan Hirnyk: Before pursuing any further the idea of a full parametric solve, or any actual equations, consider just the following simple code:

eqs := {
   x - a*b*y,
   y - a*b*x
};

In line with 'Note added', see top of thread, a and b are here considered operators acting on some functions x and y. The equation should be solved for x,y, using a²=b²=1 and ab=ba, with 1 meaning the identity map. Using solve(eqs), i.e., solving for all variables, as suggested above, which yields the solution

does not work because either x = y = 0 (the trivial solution), or the operators are expressed in terms of each other (which they cannot ever be with the ones I actually have at hand). Using solve(eqs,{x,y}) does not work either, as it produces only the trivial solution, x = y = 0. Of course, for this simple example, the solution is immediately obvious: y = a*b*x; but, as previously noted, for more complicated systems it is not.

@Markiyan Hirnyk: I fear that your suggestion will scale badly going to more complicated situations, and for the actual set of equations that I have (see above reply to vv) become completely unmanageable.

@panke: You are welcome.

@vv: It may be a premature conclusion, but using Groebner does not seem a way forward either.

PS: Perhaps I should try to create a somewhat more realistic example than the grossly simplified one above.

@Axel Vogt: Neither eliminate nor parametric does seem a way forward for the more involved case I really have (see the reply to vv below). The parametric solve seems to give the same solution as not using that option. And for more equations and more indeterminates to solve for, than the simplified example given, it seems that elimination has be be done several times over (or what?), requiring manual tweaking all the way, thus being no real improvement to just solving the equations by hand form the start. The reason, though, that I want 'Maple-automatic' solving rather than manual solving is that the equations can come in several versions, determined by some other quantities.

@vv: For the more involved case (consisting of 32 equations in 8 indeterminates with 4 side relations) I really have, simply solving with respect to all variables produces a sequence of 'solutions' none of which is actually the true solution (having obtained this by hand). One problem is that solve returns 'solutions' where the indeterminates entering into the side relations are expressed either (partially) in terms of one another, or being assigned something themselves, neither of which is of any use, compare 'Note added' above.

@vv: Thanks for your backing.

@Markiyan Hirnyk: I withdraw from this discussion with you, finding the tone of it unpleasant. For me, this site should not be like participating in a competition, it should be about collaboration.

@Markiyan Hirnyk: Yes, the expression is obviously complex-valued, as otherwise it could not equal -I. But my point is that the manifold must be a continuous one, generated by four continuous, real-valued parameters, the variables Omega, a, k, and m. Thus there can be no change between the two isolated values -I and +I, as that would be a discontinuous change.

PS: The square root has a branch cut in the complex plane, but does that affect the above argument?

@Markiyan Hirnyk: With the danger of making yet another trivial mistake, could one not argue like follows then: If k*m is positive, which I expect it to be (k being probably related to the gravitational constant, and m probably denoting some mass - the expression seems to be something related to a rotating, black hole), then the denominator is always positive. Thus the expression is a continuous function in the four real-valued variables (Omega, a, k, and m), and therefore if equal to -I in any one point, it will equal -I everywhere (because it can only equal either +I or -I, as already shown).

@Markiyan Hirnyk: Oh, yes, of course; I was just a bit too quick there.

@Carl Love: Thanks for your suggestion. It does not seem to work, though. As acer correctly expected, the subexpression of mine is known only at construction time.

I have decided to implement the suggestion by acer (a tweak of the one by Preben), because its syntax to me seems the most appealing and easiest to understand. But thanks to all; your expert advice is always highly appreciated.

@vv: Your suggestion does indeed seem to work for the above test example, now tweaked to something along the following lines:

F := (theta) -> curry([seq(unapply(u*theta*x,x,theta),u in [v1,v2])],theta):
F(phi)(y);

using only a single unapply, and thus, in line with your idea, two-parameter procedures. But I am not sure whether or not it will work, as well, in the actual setting I have. Preliminaries findings seem to suggest that it does not, though the verdict is certainly not final yet. In any case, thanks for your idea; I think I have never before used curry.