Interesting discussion. To address your initial questions about odetest and dsolve’s inability to provide a solution it is helpful to have a look at the phase space.

The problem posed in the textbook can only be answered for particular solutions that follow a special trace in the phase space of the ODE.  For the pendulum this trace is called separatix. It separates bounded motion and unbounded motion of the pendulum (highlighted in green; from https://mathematicalgarden.wordpress.com/2009/03/29/nonlinear-pendulum/).

From the phase portrait of the ODE we can deduce that all points on the separatrix are valid initial conditions for a swing of the pendulum towards the instable equilibrium point at x=pi and x_dot=0.
Furthermore, the red arrows at the equilibrium point underline that no continuous and smooth movements beyond this point at t=infinity are possible.

It is therefore justified to question whether this point (y(0)=pi and y_dot(0)=0) can represent a valid initial condition at all to answer the textbook problem. Only with a tiny initial impulse (i.e. y_dot(0) <> 0 starting at -pi) the pendulum can reach in a finite ammout of time the angle pi but will not stop to zero and continues to move unbounded.
Since y(0)=pi and y(0)=-pi (which is the same) at x_dot=0 are no proper initial conditions on the separatrix, y(t)=pi at any point in time (including infinity) is neither. From this perspective it does not make sense to ask if Maple’s solution is correct.

The separatrix can quite easily be derived from the law of conservation of energy to get initial conditions to solve the problem.

At x(0)=0 and g/l=1 (factor of the sine term of the ODE), the velocity calculates to x_dot(0)=2. These are the initial conditions Kitonum used in his solution which elegantly avoids elliptic integrals by only integrating once. Integrating twice complicates the solution considerably. Also here the limit is pi (Edit: in 1D plain text copied from the source; t equivalent to x):    

varphi(t) = 2*arcsin(JacobiSN(sin(varphi__0/2)*sqrt(C)*t, 1/sin(varphi__0/2)));
subs(varphi__0 = Pi, C = 1, %);
simplify(%);
limit(%, t = infinity)

The second integration step (integration for the independent variable) and mapping Jacobi elliptic functions to elliptic integrals of the dependent variable is something that Maple’s generic integration algorithms currently do not perform. However, you might have noticed that if you instead of y(infinity)=pi put y(0)=anyvalue odetest returns zero.

This way the symbolical result of solve is converted to a "numeric format":

evalf(solve({el1, el2, el3, el4, el5, el6, el7, el8, el9,
             el10, el11, el12, el13, el14, el15, el16},
             {a[0], a[1], a[2], a[3], a[4], a[5], a[6], a[7],
              a[8], a[9], a[10], a[11], a[12], a[13], a[14], a[15]}));

solve_numerical_reply.mw

Maple does this by convention and to be consistent. Already the input arccot(-A) is automatically simplified to Maple's convention

arccot(-A);
                         Pi - arccot(A)

Other ways of solving will fail whenever arccot(-A) appears. Like

cot(y)=-A;
map(arccot,%);
simplify(%)assuming y>=0,y<=Pi
                          cot(y) = -A

                arccot(cot(y)) = Pi - arccot(A)

                          1               
                      y = - Pi + arctan(A)
                          2               

I think you came to the same conclusion.

The only ways to get the desired output is to define a symbol for negative A this way `-A` or use an inert negation operator

cot(y)=`%-`(A);
solve(%,{y})[];
value(%)

You probably did not look at the Relational Round palette. This palette groups relational symbols containing curved lines.

Before searching the pallets, I use the Handwriting palette which works acceptable for simple symbols

I can now confirm that there is at least on bug. The bug I encountered is reproducible.

Attached is a document that I prepared to establish common ground on unit conversion with Maple to avoid missunderstandings.

In a nutshell: Something goes wrong after excecution. Maple proposes wrong units which prevent conversion. Output conversion is only possible before excecuting the document. This is a bad workaround we cannot live with. Maybe someone finds something better to get Maple back on tack.

Pasted from your example file into a new document = In the above output (evaluated and displayed inline) unit conversion is applied. Click on the output and have a look at the context panel. If you now define a new density with a miniscule m and enter rho again, the former definition is replaced by . All this happens in the math engine (the Maple server, sometimes called kernel) of Maple. (1) (2) The above new input is send to the kernel and the kernel sends the result back in SI units because no additional instructions about output formatting (i.e. unit conversion) has been send to the kernel. To format the output of the new rho (3) you either have to tell the kernel to convert the output to grams per liter (4) or do it manually for each output (with the context panel)    = The above conversion is only known to the user interface of Maple (that communicates with the kernel) Compare the following: kernel output vs output stored in the Maple document (that is processed by the user interface) (5) To make the unit formatting work without getting an error message I had to restart the Maple server. However, this does not work always. I cannot convert the following output after execution but output can be converted after loading the document. (6) Under chose unit we find something that has the wrong dimension (after execution!!!)

Download Unit_conversion_in_the_GUI.mw

An alternative to crtl-l mentioned by acer: A double click on an equation label (right to an output) inserts the equation label at the position of the text input cursor.

I do not think that this is documented but perhaps I am wrong.

Here is a variant with the SignalProcessing package. 

numsolve-1229_reply.mw

@dharr nice use of seq[scan=...]

Maple requires assumptions. Without them I have been very unsuccessfull with Elliptic Integrals.

Leaving asside the various notations (it is very confusing, see also Wikipedia) I have doubts that the output from MMA is in general valid.

(Strickly speaking at multiples of pi/2 differentiation is not possible and MMA should not have returned the integrand.)

Here is a way without integration tools. The result is not in form of a single incomplete elliptic integral. Instead a complete and an imcomplete integral of the second kind is returned. I assume that this is Maplesoft way of retruning the most general solution.
Unfortuneately there is no documentation why this is done and how to obtain a more compact output.
Unfortuneately there is no support for converting such results into a single elliptic integrals (compare this to the other solutions provided by sand15 and dharr). 
Unfortuneately there is allot of trial and error and expertise involved.

Just a tip: MMAtranslator should provide you exquivalent Maple code without the need to memorise the different conventions for ellpitic integrals.

Annother tip: Sometimes allsolutions does not work with sine expressions. In this case a change of variables can help to get all solutions (see sand15 anwser).

Download int_diff.mw

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.