The names segm returned by your geom(...) calls are escaped locals from that procedure. By that I mean that they are distinct instances of the local variable (only ostensibly having the same name).

The same goes for the [a1,b1] pairs that you are seeing, following the separate geom(...) calls. Those are distinct/different pairs of escaped locals.

Each time you invoke your geom(...) it returns a different instance of its (now, escaped) local segm. And the segment associated with that contains references to a pair of different instances of the a1,b1 (now, escaped) locals.

The geometry objects associated with those groups of distinct escaped locals are, in turn, also different.

None of these escaped locals are the global names, a1, b2, segm.

Download GeometrySegment_acc.mw

Your Question's code tries to catch wrt the error message starting as,
  "wrong type of arguments"

But the error message emitted by your later example actually has,
  "wrong type of argument"

Note that the last word in the emitted error is singular "argument", not plural "arguments".

It seems as if you couldn't catch it because you misspelled the last word.

Download CatchMeIfYouCan_ac.mw

Some years ago a decision was made to add argument coercion to the Matrix/Vector parameters of many LinearAlgebra commands.

(Below, note the ~Matrix rather than just Matrix, as the type-specfication for parameter A. That's the syntax for the coercion parameter modifier.)

showstat(LinearAlgebra:-RowDimension);

LinearAlgebra:-RowDimension := proc(A::~Matrix, $)
   1   op([1, 1],A)
end proc

I'm not entirely sure why it isn't mentioned on the individual Help pages of the relevant commands; it's possible(?) that someone imagined that people might find it more confusing than helpful to see it described in great detail on each such page.

note. Even the older (now deprecated) linalg package's commands accepted listlist/list even though their Help pages mostly mentioned only matrix/vector.

I am not a fan of this general and wide-spread use of coercion. It's a hidden performance penalty -- quietly allowing often unnecessary use of data structures which entail inefficient copying (casting to Matrix/Vector) on each call. Encouraging users to utilize the right (efficient) data structures -- where possible -- would be better than silently passing through on inefficient programming.

Download Convert_inert_IC_to_D_notation_ac.mw

You're getting that first example's error because the name x is already being used for statevariable. That's what the error message means.

It seems reasonable to me, to disallow using the same name simultaneously for more than one DynamicSystems meaning.

So, if you first change statevariable to some name other than x, you would then be able to set x for statevariable.

You could also change both in the same call.

Download DS_sysopts.mw

For your example you can find an exact symbolic expression for the maximum value of A, given x<0 and M>0.

You can plot that maximal value of A (for x=-5..0) against M.

If you're also interested in the percent loss of Amax (down from its value at M=1.2431) , against M, then you could plot that too. You could also adorn that in a few ways.

Download Help_percentage_accc.mw

You could also find the value of M at which Amax is 13% of (ie. 0.13 times) the reference value of Amax at M=1.2431.  In other words, 87% loss. The answer, shown below, is M=4.2553 approximately.

L87 := fsolve(perc_loss(M)=87, M=1.2431..10);

         L87 := 4.255250652

A87 := evalf( eval(Amax,M=L87) );

         A87 := 0.272216303

# check
evalf( ( eval(Amax,M=1.2431) - eval(Amax,M=L87) )/eval(Amax,M=1.2431) );

            0.8700000001

# check
evalf( eval(Amax,M=L87)/eval(Amax,M=1.2431) )

            0.1299999999

Download SMMS_ac.mw

In such situations I usually utilize algsubs or simplify-with-side-relations to accomplish the temporary substitution of the target subexpression by a token (since subs would fail due to the absence of the target structurally).

For a token I sometimes use a double-underscore name since that should ideally not be otherwise present. For more a more programmatic approach I sometimes utilize freeze & thaw, which also lets me skirt having to reverse the substituion-equation.

Download asi.mw

All of the above works in your older Maple 2015.2 version.

In current Maple 2023.0 you could alternatively utilize Physics:-Substitute (instead of algsubs or simplify-with-side-relations) for the first step of substiting for the target by a token. But that doesn't make it easier.

Useful might be something like (I'm making this up),
   PDETools:-Solve(eq,lhs(eq))
as a means to directly handle this whole task.

It seems that subs can handle your example in a straightforward manner,

In particular, you don't have to construct your eq_Dx equation by any manual copy&paste, ie. of a denominator in the rhs of the original. It can be formed programmatically.

Download Q20230606_ac2.mw

That latter one is like Edgardo's, except that it uses subs instead of Physics:-Substitute. (That is, there's not much especially tricky about this example.)

This is not very attractive, but agrees, for real x (almost everywhere, leaving out x=1 say).

Download ugly.mw

Here are some examples.

Adjust the various options, as wanted.  See also the Help page with topic plot,options (in Maple's own Help, or online).

Download ode_leg_lab_ex1.mw

Here is a somewhat crude approach to your problem, using Maple 18.02.

There are several ways to make it fancier, or more general (but I only had 10 minutes for it).

I made very little effort to make it efficient.

Download simp_newt.mw

[edit] Here is some rough code that shades by varied intensity, according to how many iteration it took to get below a threshold value.

(It's not very robust, as far as adjusting the max.iteration or tolerance values, but seems ok for these values. Sorry, I don't have time to improve it.)

Download simp_newt_alt.mw

ps. Apart from not having much spare time, I apologize but I'm not so inclined to make it more general for the requirement that the Maple version is 9 years and 9 major releases out-of-date.

Here are two ways:

Download subst_ex4.mw

ps. I removed this one from my worksheet, because it seemed unnecessarily complicated; the collect call is not needed.
   collect(simplify(eq),diff,
          u->simplify(u,{coeff(eq,diff(U(z,t),z))=t1}));

[edit] other possibilities include,
    simplify(subs(coeff(eq,diff(U(z,t),z))=t1,
                collect(eq,diff)));
  simplify(map[2](subs,coeff(eq,diff(U(z,t),z))=t1,
                  collect(eq,diff)));

The lhs of your equation (hidden input) is entered as,
   Int(E*r, r = 0 .. 2*sigma, varphi = 0 .. 2*Pi)
instead of as,
   Int(E*r, [r = 0 .. 2*sigma, varphi = 0 .. 2*Pi])

The GUI's Typesetting system is not pretty-printing the former in Maple 2023.0 and Maple 2022.2. Within Maple 2021.2 (and earlier, say 18.02) it does get pretty-printed as you're expecting.

Note that in M2023.0, even when not pretty-printed as you'd like, value still works on it. The former is not actually one of the documented calling sequences of int, say, afaics, even if accepted.

Fwiw, the command IntegrationTools:-CollapseNested seems to turn the former into the latter, programmatically.

There is a typical issue with nested numeric computations, where the outer process might not be able to attain some target tolerance because the inner process is not guaranteeing corrspondingly adequate accuracy.

For example, if the inner process guarantees only 6 digits of accuracy, and the outer process has a "convergence acceptance" criterion involving 8 places of accuracy. Random 7th and 8th digits from the inner results prevent the outer process from successfully converging.

This kind of thing can happen when you do fsolve of a dsolve process, or Optimization of a dsolve process, of fsolve of an evalf/Int process, evalf/Int of some other numer process, etc, etc.

Even a rough understanding of the issue can help in such situations (as opposed to flailing around). But it can get tricky. It can get even more complicated if there are both relative and absolute accuracy tolerances in play.

Sometimes the simplest thing is just to crank up the working precision of the inner process, eg. Allan's suggestion to set Digits:=18 in ss. That may bring about enough improvement in the inner results's accuracy that the outer process can also meet its own tolerances. But sometimes this can make the whole computation too slow.

Sometimes having unfortunate choices of tolerances (inner and outer) can produce results successfully, but slower than with more fortuitous choices.

Being able to relax the accuracy of the outer process while retaining, say, the compiled/evalhf hardware double precision speed of inner processes is often desirable.

For these reasons knowing the required accuracy of the outer process is a very good place to begin. Alternatively, if there is a cap on the working precision of the inner process (eg. it requires hardware double-precision speed, etc), then one might need to accept a less accurate outer result -- according to the given problem.

nb. There are also some situations where a final step of rounding to a specific number of digits in the inner process (thereby removing all innaccurate digits) can additionally help with this kind of thing. I didn't do that here.

Here is an adjustment that produces results for your three cases. Experiment and adjust as necessary. You indicated that you'd rather not raise the working precision of the inner process (involving dsolve/numeric), so instead I've relaxed the optimalitytolerance of NLPSolve.

Download test_VS1_ac.mw

The OP mentioned fdiff. If the internal methods NLPSolve uses to compute numerical derivatives is not accurate enough here (it could be a weak link in the nesting of numeric processes) then NLPSolve could be passed a user-defined procedure for objective gradient or constraint jacobian. That might leverage dsolve/numeric itself as a more robust mechanism for that part of the computation. For convenience sometimes the DE system can be augmented for more convenient&direct access to derivative results.