@janhardo I have difficulty understanding some of your sentences, which gets in the way of my understanding your goals.

Perhaps you are trying to achieve something more like one of these, in your followup.

Download some_diff.mw

@janhardo For the sake of formatting...

Download some_int3.mw

@janhardo 

@janhardo Man is the measure of all things. Of things that are, that they are. And of things that are not, that they are not.

Of course  (z-s)^(-1-n)  is the same as  1/(z-s)^(n+1) .

Also,  1/I  is the same as  -I  , and Maple converts the former the latter as part of its automatic simplification.

I don't have much interest in fiddling around to get the output in exactly the right format as you seem to need. Of course it can be done, programmatically. But I don't have time for that minor difference.

The key aspect of answering your query lay in attaining the general derivative, by making the differentiation actually happen for general, unspecified n.

I did that.

I also showed how the result (which came here in pochammer form) could be converted to factorial form.

Formatting exponents and positions of multiplicands in the result is a relatively minor aesthetic. 

@C_R The name `≟` that you found is derived from an HTML entity. I didn't use it because in my Maple 2020.1 for Linux the question mark portion is rendered unusefully small. By happenstance the leading ampersand in that name allowed you to utilize it as an infix operator.

You asked about my use of single left-ticks (aka back-ticks) above. Those are often called name quotes in Maple, because when they wrap some characters the result is a Maple name (aka variable).

The Maple GUI's 2D Math printing mechanisms know that certain special forms of name are to be rendered specially. The first example in my Answer is an example of such a special name. The form (between the left-ticks and the # and semicolor) looks somewhat like MathML.

There is also a special functional form that produces similar renderings. Both the special names and the functional form involve unevaluated returns, ie. they don't evaluate to anything else. The GUI just knows how to render them as marked up math.

`#mover(mo("="),mo("?"));`;
lprint(%);

Typesetting:-mover(Typesetting:-mo("="),Typesetting:-mo("?"));
lprint(%);

The second of those is easier to programmatically generate. I used it in my Answer's example, with a procedure as a special print-extension, so that I could make function calls which rendered as wanted.

Neither of these two typesetting approaches is documented, despite being quite powerful and useful. They've been used many times to get decent solutions to requests on this forum.

I also described using "Over" item from the Layout palette to place an ampersand over a question mark, while in 2D Input mode. When I do that I got a good rendering, and the thing that it actually creates is one of those special names:

   `#mover(mo("="),mo("?"))`

But that can't be used as an infix operator and so is not ok for executable Math (...I padded with spaces, to get multiplication implicitly).

Using the handwriting palette is a dead-end approach, IMO.

@Delali Accolley What values of tau_l are possible?

Setting Digits=11 (up front, except for that problematic final fsolve attempt) works in my Maple 2021.1 for tau_l=0.6 as well as tau_l=0.8.

But what other values of that parameter are you needing? Another approach might be required, but we don't know what is your full set of candidates values.

Also, how large are you willing to accept as the residuals?

Also, what are the valid ranges for the variables?

It may well be better to tackle this as an optimization problem, using either Tom's approach or the DirectSearch (version2) 3rd party add-on from the Application Center.

We can deduce sigma__2 >0 from eq1, given that both d and P__2 are greater than zero.

And if we explicitly utilize that further assumption sigma_2>0 then a closer form can be attained:

Download suggestion_ac.mw

We can also get that same closer form by passing both d>0 as well as eq1 (the original equation for sigma__2) as additional assumptions, since altogether that allows Maple to figure out that sigma__2>0.

So here we're using only the stated original assumptions as well as the original equation:

I sometimes see that message, but I don't recall it ever being accompanied by being bumped out of the current procedure level. I utilize "into" far more than "next", however.

@nm The return value L is most certainly not discarded by map, contrary to your claim! That's the whole point. The return values of f are passed to `+`, since the original expression r (on which map is called) also has `+` as its zeroth operand.

These various claims you wrote are all untrue:

 "Since in the map, the output of the proc f() is not used at all." 

 "...so each time f() is called, the return list (which happened to
  be current value of L) is discarded by map."

 "Return value from f() is not used inside map."

Each of those is statements is wrong.

@Claybourne If I reexecute your whole document (eg, using the !!! triple-exclam button from the Maple 2021 GUI's main menubar) then I get the same output that Tom showed, as expected.

@Claybourne It looks as if you might (still) have GUI-based numeric formatting on that output?

(It's difficult to tell because you didn't attach the corresponding worksheet; you gave just an image of output, which is not very useful.)

@tomleslie Tom, you wrote,

  "When you write i[`1d`]  in Maple you are creating a TABLE with (so far)
    one indexed entry, whose index is the name '1d'."

That is not true. A table is not created merely by making an indexed reference.

(A table is created by assigning to an indexed reference of an otherwise unassigned name, but it is not created merely by using such an indexed name.)

An alternative approach, using the procedural colorscheme functionality available in Maple 2016 and later.

The plot3d command can produce a MESH that gets rendered here like a space-curve, but it doesn't render the color. So the MESH (of double necessary size, in one dimension) can be turned into the appropriate CURVES substructure, and the color data re-utilized.

This allows either HUE (single procedure) or RGB (three procedures) colorspaces. The procedures take three arguments (for x,y,z values) and thus can be quite general and efficient.

The memoization (option remember) on the returned dsolve procedures is added because plot3d needs at least 2 for the second (dummy) parameter, specified in the grid option.

Download spacecurve_shaded_3.mw

I'd like to mention that I think dharr's workaround using tubeplot is ingenious. I have long admired his good responses on this forum. I simply felt that a topic as basic as coloring a 3D curve might be addressed slightly better.

I'll add that the syntax and usage of my solution (using some code developed long ago) is already a reasonably close match to what the OP described in the original Question.

And I'll also note that I too have found that that the ISOSURFACE plotting structure cannot properly be generally colored. (I have previously submitted a bug report on that.)

You are welcome, as always.

I'd like to mention that I consider this (which you cited) as a relative poor programming technique for such extraction from the listprocedure:
   T,X,V,PX,PV:=rhs~(sol)[ ] )
The problem is that is depends on matching the order of terms in the list. If that order were changed (ie. lexicographically) inadvertantly later on then a mismatch could produce wrong results. I much prefer using 2-argument eval to extract rhs's in a targeted manner.

I consider using tubeplot here to be somewhat of a kludge for a proper 3D curve.

The color procedures provided by dharr involve even more calls to X(t) and V(t) and using memoization there can bring an even greater relative improvement. (Though it's still not as fast as can be done by building a curve, and that difference increases with numpoints.)

Download spacecurve_shaded_2.mw