For the case of a plot output you could select (mouse-pointer) and copy the manipulated plot, and then paste in a new exec-group (say), below. Then comment out the input line.

More generally, you could do the following:
  - ensure that the menubar's "View" has "Markers" toggled on.
  - use the left Marker-border to right-click and select the whole exec-group
  - use the left Marker-border to right-click and put an annotation on that exec-group (For me, this gives it a light purple background)
  - comment out the input line
This can be later undone by removing the annotation.

For me these effects side-step the menubar's "Remove Output from Worksheet", or !!! "Execute the entire worksheet".  See attached for example of each, made with Maple 2023.0.
anno_ex.mw

I believe that these are (mostly all) different students.

When I see the same question I delete it as a duplicate.

I believe that it could reduce this behavior if members stopped answering them separately.

Download arg_ex0.mw

Collapsing those conditions seems not so straightforward.

Are you hoping for an effect that looks something like this?

Download pl1.mw

Download pl2.mw

By changing the difference of the pair of sin&cos calls into a product we can give solve a helping hand.

Solving the product is, naturally, quite easy.

Download sc_solve_2023_2.mw

Here's a more programmatic variant of that, but without having to manually enter a cos call within uneval quotes,

Download sc_solve_2023_3.mw

And here's something with another kind of intermediate conversion, but also with a result more readily understandable than your straight solve attempt (which is large, with RootOf's).

Download sc_solve_2023_1.mw

I will submit a couple of bug reports about various weaknesses discovered here in solve and trigsubs. That is: the original unwieldy result from solve, and trigsubs not knowing how to handle some variants on the sum/difference forms.

It seems that the (SSL) certificate for this site had expired, preventing https access. (http access was still possible I think.)

It may have been fixed.

In your second question you are missing the multiplication between 10 and Unit(m/s).

As you have it, in 1D plaintext input,
  10Unit(m/s)
it is not valid Maple syntax.

In pretty-printed 2D Output the multiplication is represented implicitly by a space.

Download Units_ac.mw

Performing simplify-with-side-relations does a kind of normal form operation in a polynomial sense.

It doesn't perform every other kind of simplify action. This is documented on the Help page with Topic simplify,details.

In that page's Options section it says,
  "Invokes only the simplification procedures specified by the additional names."
followed by a list of names. The word "siderels" is one of those names listed (and which is a cross-reference I gave at top). Yes, "siderels" itself is not an actual option name proper, but it's listed there since its relevent option names are governed by that same principle.

For example,

Download simp_siderels_1.mw

Apparently the two-argument variant of EllipticE gets covered under EnableTypesetRule with the token,
     "EllipticE2"

So, that case gets covered for me (M2023.0) if I instead do it as,

   Typesetting:-EnableTypesetRule({"EllipticE", "EllipticE2", "EllipticF", "EllipticK"})

You can also enable it for all the special functions about which it knows, with,

   Typesetting:-EnableTypesetRule(Typesetting:-SpecialFunctionRules)

I don't know why the 2-argument E and F are not rendered in bold.

I will submit a bug report against the lack of bold, and the lack of documentation on the Help page about the multi-argument variants.

ps. I also see that "EllipticF" is adequate to cover its (sole!) 2-argument case. The naming scheme thus seems a bit unhelpful. But there's enough documented detail to see that this aspect is key. (It's also seen in the Typesetting:-RuleAssistant's popup details...)

The problem appears to lie in the new (Maple 2022, default) adaptive=geometric algorithm.

If you force the (older default) adaptive=true then the whole region gets plotted.

Download PlotIssue_ac.mw

I will submit a bug report against this example.

note: For this example it happens you might also use adaptive=false, though in general (other examples) that will not attempt to refine the curve near portions with high curvature or save space in portions that need fewer points.

See also the adaptive Help page.

Here's a kludge to make the datasetlabels=contents result look a bit better.

This is customized for this example, and won't handle many more elements without further adjustment/tweaks and/or reduction of font size. To be more general it would have to do more work, eg. also act according to where the "content" strings occurred, etc.

Download DigVenn_ac.mw

Here are two simple alternatives, for your example. I'd generally favour the former over the latter.

restart;
decisions := "accept", "reject":
T := 2:

`if`(1 > T, decisions[1], decisions[2]);

               "reject"

eval('`if`'(1 > T, decisions));

               "reject"

You asked why your problematic situation occurs. The `if` command has special evaluation rules, in which its arguments are not fully evaluated up front in the usual way.

One common motivating example for this design is that NULL can be passed (including the case of NULL as a 2nd argument), with the separate arguments recognized. If the argument sequence were flattened in the usual way during up-front evaluation then the following example would not work as intended.

restart;

map(u->`if`(u>2, NULL, u), [-3,7,1,9]);

          [-3, 1]

Here is another example, in which the desired behaviour also relies on the non-flattening of the argument sequence (possible by virtue of the special evaluation rules). Under usual evaluation rules the following would behave like a function call with four arguments.

restart;
p1:= A,B:
p2:=C:

`if`(3>2, p1, p2);

             A, B

Note that a workaround construction like,
   eval('`if`'( ... ))
would break the functionality of the first two examples I've given, because the forced full evaluation flattens the argument sequence.

The behaviour is somewhat similar during the initial construction where you called piecewise, which also has special evaluation rules.

note. The ifelse command also has special evaluation rules, and ought to be mentioned on the cited ?spec_eval_rules Help page.

This OP's first example is documented. The assuming facility doesn't place (its temporary) assumptions on variables it doesn't see, ie. only hidden within a procedure. From the Example section of the Help page for Topic assuming,

   The variable a is inside the body of f; the assumption that a > 0 is
   not effectively used when computing f(1).
   f := x -> sqrt(a^2) + x;
     f := proc (x) options operator, arrow; sqrt(a^2)+x end proc

   f(1) assuming a > 0;
                             (1/2)    
                         / 2\         
                         \a /      + 1

   For these purposes, you can use the Physics:-Setup command
   with its assumingusesAssume keyword, or use assume itself...
 

And so,

Download assuming_exx.mw

The OP's second example is quite another matter, related to the current limits of D functionality.

You can specify a reasonable view, and get a more usuable result.

AnimationCercleTrigoFonctiTrigo_ac.mw

You could also add the discont option to the plot of tan, if you don't want to see the vertical lines at the discontinuities, eg.
    plot(tan(x), x = 0 .. t, discont)
Then you could get,

In your Maple 2021 the values of F can overflow if computed at hardware float double-precision, for the upper portion of your range omega=0..200. That makes the upper portion of the plot blank, ie. missing the curve.

There are a few ways around that. One of the simplest approaches is to set Digits:=16 (or higher) at the start of the document.

If I do that in Maple 2021.2 then the following plot appears when I re-execute the whole document:

Plot_determinant_value_vs_omega_ac.mw

In current Maple 2023.0 the numeric problem in hardware double precision is dealt with automatically, and the upper portion of this curve is handled ok by default.

Also, the error message you showed indicated that at some point you may have accidentally assigned the value 160 to the name omega. You'll need to keep that name omega unassigned if you intend on using it as the plotting variable.

Notes: By default setting Digits:=16 allows software floats to be used in the compution of F during plotting, with a wider range of values attainable without overflowing and generating Float(undefined). Another simple alternative is to set  UseHardwareFloats:=false  .  There are also slightly more complicated approaches, including reformulation of the expression F.