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.

It looks as if you are somehow substituting in a numeric value for x (which you say is supposed to be the dummy variable of integration).

Why don't you upload and attach a complete worksheet (and data values), in a Comment. You can use the green up-arrow in the Mapleprimes editor to do that.