@lcz I agree, my code actually tests for a cutset, which is a minimal cut, but not all cuts are minimal. Apologies; I sorted all this out before, but forgot about this distinction.

"A cutset S of a connected graph G is a minimal set of edges of G such that removal of S [dis]connects G into exactly two components", p.43, K. Thulasiraman and M.N.S. Swamy, "Graphs, Theory and Algorithms", Wiley 1992. doi:10.1002/9781118033104.

The stackexchange algorithm involving contraction detecting extra edges with loops is not easy to implement in Maple with its Contract or ContractSubgraph commands because it doesn't keep track of where loops came from. But one can just check for extra edges that are in one component before contracting. Here it is: 

Download IsCut.mw

@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.