note: On Linux the bin/maple script is an intended front-end for invoking the cmaple executable. Ie. `maple` sets certain key variables, and then calls `cmaple ` with arguments. (Normally, one wouldn't call it directly on that platform.)

(I had not noticed that the OP was attempting to call `cmaple` directly. Sorry, my eyes saw what I was expecting. Vote up for phil2!)

On Windows, it's different.

@C_R Yes, the Classic GUI was shipped alongside the Java GUI for some releases.

@C_R Let's not call the old (Maple 2024 and earlier) Java GUI as "classic".

The term "Classic" has meant the non-Java pre-Maple8 GUI for a long time, including in Maplesoft's documentation. It'd be confusing to re-use the term.

Please forgive me for editing the word in your response.

The problematic part is actually split across two separate Execution Groups. The "end proc" is in the second one.

That fact is obscured because both have XML property view="presentation" (ie, the red chevons don't show, and F4 doesn't join them).

The simplest is to not try and Copy&Paste that.

I don't know exactly how you got it into that state.

Is there a subdirectory "afm" (with about 13 files in it) under your Maple 2025 installation?

Eg, on my Maple 2024.2,
    /usr/local/maple/maple2024/afm

Does it work in your Maple 2024?

Btw, from the Commandline Interface (CLI) one might do it as,
    plotsetup(cps, plotoutput="full_file_name.ps");
to get both the filename extension as well as a colored red curve. Also, the plot driver is slightly different wrt orientation default (portrait vs landscape) as well as curve thickness. That calling sequence seems to act the same in the GUI, regardless of whether "cps" is the plot-device or whether the filename extension is explicit in the supplied name.

Please either add closely related queries on this as addtitional details here (in a Comment, say), or use the Branch button at the bottom of this Question to form a new Question thread with cross-reference links that get added automatically.

Also, if possible, you could attach an example that produced the system of equations (that use, or for which you want to use) the SemiAlgebraic solver.

When using the Mapleprimes editor's green up-arrow to upload a file, the 2nd step can be "Insert Link", even if the alternative choice of inserting the whole document (inlined display) fails.

A workbook file (extension .maple) can be first zipped up (.zip) in the OS, since the uploader doesn't recognize the former.

Otherwise, you could explain precisely how uploading and attaching your Maple file is failing.

@Saalehorizontale Unfortunately (for me), that's not actually and explicitly what you wrote in your Question.

@Carl Love Thanks, I missed that.

I hazily recall seeing the real[i] selector mentioned somewhere, but now I can't find it.

@Carl Love It seems to me that it'd also be useful if the OP were to include the conditions 1 < y, y < 2 in his solve call (as well as those assigned to area)

@mmcdara A single call to the eliminate command provides this condition directly.

@C_R Your worksheet shows a result of NULL from the last statement, the call to solve.

@Scot Gould 

I edited my Reply above, to show an actual wrapping/replacement proc for this. Please let me know whether it works ok.

Have your examples of 1) and 2) been reported?

It's slightly confusing to me that you've chosen only this Question thread to mention earlier problems that you say are not rare. If they are not rare and causing problems for several people then why not post/report on them earlier?

(please report problems/hangs/etc.)

@Scot Gould There is no super-convenient way to set a new/different default for an arbitrary Maple command's options, while also retaining ability to call it by its original name.

But, you could wrap it, eg. (possibly for an init file),

unprotect(Explore);
__kopts := kernelopts(':-opaquemodules' = false);
__Explore := eval(Explore:-ModuleApply);
Explore:-ModuleApply := (ee::uneval) -> __Explore(ee, 'adaptview' = false, _passed[2 .. ()]);
protect(Explore);
kernelopts(':-opaquemodules' = __kopts);

The above is slightly more complicated that a usual "wrap", because Explore is an appliable module and also Explore:-ModuleApply's first parameter has special evaluation rules.

Personally, I wouldn't disable functionality by default just to avoid an (apparently) rare issue. I'd just change my usage on the rare occsasion that needed it, and submit a report.

You could remove options remember and system from targeted procedures. That would disable the usual remembering of regular function calls to that procedure.

And for each procedure you'd only have to do it once per session, up front. That up-front act could then cover all your subsequent simplify calls.

For example,

strip_memo.mw

To be most effective you'd want to do this also to the procs internal to simplify. So you could map the act over a list of the relevant proc names. (There isn't a convenient automatic way that'd be analogous to forget's subfunctions option.) There are more `simplify/`... classical-extension procs, btw, including,
`simplify/recurse`
`simplify/normal`
`simplify/normal/check`
`simplify/normal/test`
`simplify/factor`
`simplify/do`

Anyway, the point of this is that you can disable remembering by simplify and its internals (if accomplished via usual procedure calls), which was your followup question. But I still think that my original suggestions to either wrap :-simplify or use a module export (so as to be able to forget, each time, without wide code changes by you) are safer in general.

ps. You've made the claim before that your above-described kind of crash is due to memoization. It might be. But it might be due to something else.