@vv @Christian Wolinski Thanks! Interestingly, I was using a more complicated expression earlier, and I got an error message:

with(Logic):
q:=&or((&not x[2]) &and (&not x[8]),(&not x[2]) &and (&not x[true]),&and(x[3],x[9]
,&not x[true]),&and(&not x[3],&not x[9],&not x[true]),&and(x[2],x[3],x[8],x[9])
,&and(x[2],x[8],&not x[3],&not x[9]),&and(x[3],x[true],&not x[8],&not x[9]),
&and(x[9],x[true],&not x[3],&not x[8])):
SymmetryGroup(q);

gives: Error, (in Logic:-SymmetryGroup) not in conjunctive normal form

so it can test. So then I didn't think about the form, which was a mistake. I'll submit an SCR about this (and Normalize)

@mmcdara Not sure what the OP wants; let's see. I would think a cycle in the underlying (undirected) graph could correspond to 0,1, or 2 directed cycles (neither direction works, clockwise works or counterclockwise works but not both, both directions work). Perhaps like this:

Download Cycles.mw

@sursumCorda I guess that's what the help means by "The isolve command has some limited ability to deal with inequalities." In my experience isolve is limited. In this case, as you probably already tried, you can just inelegantly iterate through all the _Z1 etc values, (Iterator:-Multiseq might be a little faster.)

Download algeqns.mw

@Christian Wolinski Definitely unexpected to get a simpler RootOf here - documentation for convert,radical says "The conversion can fail if Maple cannot find radical expressions for the roots or if the correct radical expression cannot be selected. If the conversion fails, the RootOf remains unchanged." [my bold].

@sursumCorda If you know which RootOf you want the answer in terms of, then Algfield will help.

Download Algfield.mw

@Zeineb The Routh-Hurwitz 'array'  treatment is equivalent so will lead to the same answer. If you got the polynomial from a matrix, then working from the matrix (or even the original differential equations) can sometimes be easier. For example a symmetric matrix proves real roots, but that is harder to tell from the polynomial.

@Axel Vogt Creative approach! (gfun is now a standard package within Maple.)

@C_R I branched it off to here

@C_R Interesting. Yes, the index=real[4] RootOf does not behave like a typical RootOf in some respects. Normally evalf on a RootOf would give a numerical value but here it returns unevaluated.  This would normally be a way to work toward an exact solution, since convert(RootOf(...,numeric value),radical) could then be used.

@sursumCorda A combination of implicitplot (plot_real_curves is sometimes too slow) and algcurves:-singularities can track down the roots. 

Download algcurves.mw

For the second one, there are only singularities, and I'll let you break them down into all the subcases.

algcurves2.mw

@C_R  Interesting about index = real[4]. I've not seen that before in many years using Maple, and the stuff on the forum isn't clear about it being a bug or not. Perhaps it is a bug in the documentation. There do seem to be just six solutions, from plotting the curve with algcurves.

Download algcurves.mw

@Christian Wolinski I sumitted an SCR.

Use the green up-arrow to upload the worksheet.

@tomleslie @mmcdara Well, @nm asked for "a more elegent way to remove any entry in piecewise which has undefined in it". I didn't really answer that for the general case, but did for the case in question with a Heaviside function. As always, Maple considers the general case and one needs to be careful in special cases. I'm sure @nm will consider that. However, in the context of laplace transforms outputting the unit step function is fine because integrals are involved. In fact taking the Laplace transform of the different outputs gives the same answer:

Download Heaviside.mw

For the general case, Maple straddles the two extremes of treating Heaviside as a function or a distribution, and so for other applications I agree the unit step function might not be appropriate.

@Rouben Rostamian  In Maple 2022, ?coords takes me to a very helpful page "Coordinate Systems Supported in Maple" which makes this clear. (This page wasn't so easy to find in the online help.):

"(**): There are two widely used conventions for how to represent spherical coordinates: one is used more in physics and the other more in mathematics. The only difference is a swap of the second and third coordinate: the vector represented by 
                           "u, v, w"

 in one convention is represented by 
                           "u, w, v"

 in the other. The plotting library, the changecoords command, and the VectorCalculus package allow you to use the coordinate system names spherical_math and spherical_physics to refer to these coordinate systems unambiguously. You can also use the name spherical; its behavior is as follows:
– If neither of the Physics and VectorCalculus packages has been loaded (using the with command), then the plotting library and the changecoords command will interpret spherical as spherical_math.
– If either of the packages Physics or VectorCalculus has been loaded, then the plotting library and the changecoords command will interpret spherical as spherical_physics.
The VectorCalculus package will always interpret spherical as spherical_physics.