I do not know whether there is a complex valued solution. If there is none, Maple should return nothing.

To your question: Its an old bug. Convert is called without the first argument.

With assuming positive this call does not happen and 2 solutions are returned.

restart;
ode := diff(y(x), x) = 3*(y(x)*x)^(1/2);
IC := y(0) = 2;
sol := dsolve([ode, IC]) assuming positive;
allvalues(%)

Note Kitonums workaround should be more general than assuming positive because only in case y(x) and x are complex his workaround cannot be applied. Assuming only  x::real on the other hand and evaluating the RootOf expression with allvalues returns a solution with _Z1 placeholders which for negative x returns more solutions than Kitonums solutions.

I did not further investigate the question whether the single solution returned by Kitonums is equivalent to the solution with x::real or whether the single solution is really the only possible one (i.e. valid also for complex valued x).

Have you had a look at this guide:

https://www.maplesoft.com/documentation_center/Maple2024/ProgrammingGuide.pdf

Phaseplot shifts the phase by +360 degrees because it "exceeds" -180 degree. 

Perhaps because of the following: In a closed-loop system a phase lag of more than 180 degree effectivley changes a negative feedback to a positvie which leads to instability. An engineer looking at the phase plot would immediate interprete a postive phase as a sign of control instability.

However in your case there is no feedback and the phase lag is indeed larger than 180. For me its not a good implementation (if not even bug). 

You did nothing wrong. See how the phase snaps back to negative values (also in Maple) when one pole is removed from G:
 

Download Phaseplot.mw

You say G1=G3. and G1 := 0.01542607158831807808

I cannot confirm the 0.025 for G3

Your comment on G3

The read part reprocessed

1 - (0.9938295713 - 0.6)/(1 - 0.6)
                     0.01542607175000000000

For me all looks fine appart from the comment on G3.

For G2=G4 the formulas for G2 and G4 do not match.

It's a weakness of output formating not a bug. Automatic simplification removes the 1

1*Unit('mm');
                            Unit(mm)

The result is not what we want to see but mathematically correct. Even evalf cannot make a 1. appear since the 1 is removed completely.

@Maplesoft: Please provide solution to add a 1 to single units. It's not at all text book style to remove the value of one form a unit.

Update: A workaround with evalf

Download round_with_units.mw

Before browsing palettes I would give the handwriting palette a try. 

The symbol you were looking for is listed under the Relational Round palette. If the palette is not visible: Use right click on the palettes -> show palette 

The arrows are kind of a standard in most applications and operating systems. 

Since the integration of Maple in the desktop windows manager of Windows is not completed I think we will get them. It's a must. 

For the time beeing if you are on Windows you can use Maple for screen readers which is installed by default.

It seems that PDEtools:-Solve cannot dentify the dependent and the independent variable to integrate the ODE in eq whereas solve simply isolates D(y)(0).  

Until a fix is provided, you can push on the debug button next to the interrupt button and then quit the debugger.

Or you can use the Maple screen reader version (which I do).

I think this new warning is for the case that more than one mserver.exe are in use. This is already the case when you start Maple. There are two mservers running (whatever they are doing). These will not profit from the fix. Most times this will not matter but theoretically it could if the fix is relevant for these two mservers

You could try solve (I expand here on vv's answer):

P := numer(normal(C1 - C2))/(lambda*varphi):
params:={indets(P)[]};
conds:=seq(i>0, i in %);
solve({P<0,conds});

However, Maple is not comming to an end because too many cases have to be looked at (where cases are relations between the parameters). To better understand the nature of the solutions Maple has to compute below is a much simpler example

Download simple.mw

For 1:
I do not understand. Are you talking about lists, sets or sequences? For sets (i.e. formed with {}) Maple orders the output. For list and sequences the order does not change. You can send an example to make it clearer (use the green arrow)

For 2:
You can insert a table with two columns and one row. Leave the first column empty and adjust the width to the indentation you want. In the second column enter the bullet points. If you want more space between the bullets and the text, use three columns.

For 3:
You find Format Tab navigation in the screen reader version of Maple 2025. The Maple documentation is not fully up to date for the new GUI (such things take time). I cannot find Tab Navigation in the new GUI and it might not exist. With the older GUI I could never make Tabs work.

It's this call to genpoly in evala/inv/heuristic which causes the hang. The argument mods(r,n) is effectively a too large integer. genpoly uses GMP because GMP can also deal with integers.

Timelimit is a Maple kernel function. When the kernel calls an external dll the kernel(including timelimit) waits for the external function to finish. Waiting means not doing anything. The kernel is on halt (is inactive) and can therefore not kill/terminate the running dll. Only the operating system can do that. To avoid such situations, I guess, Maple must check the parameters before calling the dll. Not all dlls are the same. Some might be able to communicate from time to time with mserver.exe (i.e. waking mserver.exe up)

That my hypothesis.

Download toxic.mw

What speaks against

simplify((A/B)^2)
                               1

>We can show that B never gets complex.

(is(0 < (-8*x - 16)*exp(x/2) + x^2 + 4*x + 16*exp(x) + 4) assuming real);
                              true

Meaning B is postive for x>0 and negative for x<0. This is the same for A which means that the squaring in simplify((A/B)^2) is not removing a -1 in A or B when A and B are of opposite sign. Correct!?!

Simplify could apply the same piecewise reasoning to (simplify(A/B) assuming real). Below is a sketch of this approach far from beeing a propper solution. For general use a piecewise investigation of the occurence of complex expression and signs must be implemented.

>  interface(version); (1) >  restart; >  A:=-x*(x - 4*exp(x/2) + 2); B:=x*sqrt((-8*x - 16)*exp(x/2) + x^2 + 4*x + 16*exp(x) + 4); (2) >  plots:-display(Array([plot(A,x=-3..3),plot(B,x=-3..3)])) >  Digits:=16; seq(MmaTranslator:-Mma:-Chop(A-B),x=-2..2,.1) (3) >  simplify(A-B); (4) >  simplify(A-B) assuming real; (5) >  simplify(evala(A-B)) assuming real; (6) >  simplify(normal(A-B)) assuming real; (7) >  simplify(A-B,exp) assuming real; (8) >  simplify(evalc(A-B)) assuming real; (9) >  chk:=proc(A,B) if(((is(A>0) assuming positive) and (is(A < 0) assuming negative)) and (is(B>0) assuming positive) and (is(B < 0) assuming negative)) then    if is(simplify(A^2/B^2)=1) then       print("A equals B for real valued x")    else       print("chk cannot confirm that A=B")    end if; end if end proc: chk(A,B); (10)

Download show_same_may_3_2025-1_piecewise.mw

Solve cannot solve for H[j] because Maple does not know for which j a solution is wanted.

Look at this example for N=3 where j can be 1, 2 or 3

Download solve_for_H[j].mw