@ttonon Yes, you can define such procedures (f2,f3, or f[2], f[3], etc) and then generate equations which utilize them in the terms. The limits (in principle) of how many variables and equations are very large and are not approached by what you've described so far. What may well happen, though, is that there are practical limits.

As the number of terms of the equations (and how involved they are) grows the necessary working precision required to avoid numeric round-off error may well grow. And if these equations are highly nonlinear then the difficulty in generating staring points which converge to a solution may well also increase. These considerations may greatly affect how long it takes to find an acceptable solution. It may also happen that some of the equations's residuals may only become close to zero (but not ever attain zero, or cross it if sign is accounted for depending on how it is expressed) and as such it may be better taken as an optimization problem rather than a root-finding problem. It can get trickier still if you only want to accept some of the equations' residuals becoming very small but not others, or they vary significantly in scale. These issues can affect any numeric solver, and not just those implemented in Maple.

That is why it's difficult to say more without good details of your equations. A smaller working example could help, which you might upload and attach here.

If it turns out that your examples are better approached as global optimization problems then it might be that the DirectSearch add-on package (free, in this case) would be one of the better ways to try and tackle it from within Maple.

What compression format do both have, if any? Perhaps it differs.

Show how far you've gotten with this homework question so far.

@Stretto You wrote, "It's hard to describe", while still omitting to upload a worksheet that reproduces your issue.

What have you been able to do so far with this homework question?

The Maple 2018 changes were for the univariate case, not multivariate systems.

Do you mean typeset 2D Input with a slanted blinking cursor "|", versus plaintext 1D Maple Notation input with an upright blinking "|"? The former is usually in black, by default. See Valerie's response.

Or do you mean that there is a red "> " prompt (ie, an Execution Group) but that sometimes both it (and any 1D Maple Notation plaintext input) appear in bold red and sometimes in a thin red? I have seen this sometimes when copy&pasting to/from new and very old versions. In this scenario the bold and thin prompt and plaintext input are the same -- it's just a GUI rendering glitch.

@macrobbair Why don't your attach your worksheet to a Comment here?

See this previous Question.

You can find help on initialization files by querying the Help topic:
    worksheet,reference,initialization

You can set defaults for 2D plots using the command plots:-setoptions . (See also plots:-setoptions3d)

Download setoptions.mw

@Carl Love There is a Typesetting:-EV, designed for use immediately within a call to Typesetting:-Typeset which has special evaluation rules.

But I don't see that being necessary here. The OP's claimed issue is odd. I wish people were more helpful by simply uploading worksheets that exhibited a problem, rather than merely describing it vaguely.

Perhaps you have used a plain `=` instead of `:=` ?

The former creates an equation, while the latter does an assignment. Perhaps you are trying to assign the earlier Matrix result to some name, but have accidentally only made an equation?

@jum Resorting to optimization due to (likely unnecessary) loss of precision and introduced inconsistency is an inferior numerical approach, as I mentioned previously. It seems that the numerical inaccuracy of your final results here might be acceptable to you. I wonder whether that would remain true for other examples.

@jum Why are you applying evalf when forming the equations?

Do you realize that can incur roundoff error and loss of precision, possibly resulting in a consistent exact system becoming (unnecessarily) an inconsistent floating-point system?

You can try constrained optimization (instead of rootfinding) of an ostensibly inconsistent floating-point system. But it's usually much better to work with a consistent exact (or non-prematurely-truncated float) system if possible.

The problem is not "just" as you gave it. The more details you supply the better chance someone else can figure out the problem.

Why don't you give us the full details, including the background problem and the full code that produces your equations?

That might avoid a back and forth guessing game.