@acer 

The colon convention for help topics would definitely have helped to avoid wrong conclusions on syntactical equivalence. The colon convention should be introduced everywhere. Since this takes time some explanations in the description of the help system could clarifiy that there are also older converntions.

I have tried to reconstruct the searches that I have performed for command extensions and indexed procedures. For extensions I tried / to find out more about uses of /

Similarly, I tired [] to find out more about uses of square brackets.

Here, not even the help topic ?indexed is listed. I don’t now whether this page would be an appropriate place to mention indexed procedures. At least one could point to other resources providing more information on that topic. I also cannot see a reason not to officialise the term indexed procedure.

@nm  No change with physics update

@Thomas Richard 

Same for me with Maple default settings (fresh installation, no special settings)

@acer 

It takes time to catch-up with your replies because they require close studying and lead to more questions.

If you do not mind, one of them would be: Are indexed procedures stored in tabels? Or: is this a special type of data structure?

Thank you for your time!

@acer 

Simplify[sqrt] is listened under “See also” on the simplify help page. On the other hand, simplify,details lists this option under “See also” as simplify/sqrt. This suggested equivalence to me. If additionally, equivalence is assumed between library calls and extensions, improper use of command options is almost unavoidable.

I now understand why my command option trials gave such an inconsistent outcome.

I am attracted by indexed procedures/commands because this seems to be the only way in function composition to pass arguments. Now I learn that not all options can be used as an index. Is there a way to check what index (if any) is implemented?

Your explanations are more than valuable. In this case I feel that part of it should be documented because even after careful studying the documentation, at the best, it (the explanations) could be guessed. Not my prefered way to work with a language.

@Preben Alsholm 

I have taken the first examples from ?simplify,sqrt and ?combine. I did not expect that they work without options. Probably some recent enhancements that did not propagete to the examples.

I modified the examples in the hope to get a better understanding. This explains part of the confusion.

The indexed procedure example is good. I have not seen it this way in the documentation. The closest I found were  "Objects in Indexed Function Calls" in the programming guide but this is more about object oriented programming I guess.

Thank you

@acer 

Thank you for the explanation. I was mislead by the scale, which gave me the impression as if a function call took place.

I do not get the same if I do

E := t -> 0;
diffeq := D(C)(t) = E;
sol:=dsolve({diffeq, C(0) = 0}, {C(t)}, numeric);
plots:-odeplot(sol,t=0..10);

The comment about linear fits was more of general nature and towards measured (noisy) data in combination with piecewise linear fits. This potentially could cause problems with solvers trying to integrate with a certain accuracy.

@sand15 

Thank you. There must be more than one path to deal with the unavoidable case analysis depending on the relations between a, b, c, d, t.  I have updated my response for a case where b abd c cannot be freely chosen.

Since the location of the pole at x=-t/d with respect to m and n is important I would (for a new attempt) rewrite the problem this way

(f*x^2 + g*x + h)/(x + p);
                            2          
                         f x  + g x + h
                         --------------
                             x + p     

to have one parameter less to deal with. Maybe helpfull if the OP is interesed to reduce the set of possible solutions.

@acer
Now its clear. There is use for functional operators and unapply, which both can produce the same output.
Thank you for the detailed answer.

@acer 

Beautiful! Your answer anticipates a follow-up question.

However, I still haven't figured out why my "poor man's attempts" didn't work.
In the meantime I found that the arrow operator and unapply are treated differently.

Using unapply, my attempts can be fixed. 

for i from 1 to 5 do 
   x-> `^`(x,i);
   unapply(`^`(x,i),x);
end do;

But this is somehow not satisfying because up until now I thought unapply and -> are equivalent.  Aren't they?

x -> `^`(x, i);
unapply(`^`(x, i), x);
         proc (x) options operator, arrow; x^i end proc

         proc (x) options operator, arrow; x^i end proc

@acer Thank you. That makes sense.

An example of "the" equations would be helpful to better understand what you are trying to achieve

there are no determinants in your post

@Ronan 

The start page is another hard to reproduce trouble maker. Have you tried to disable it.

@acer Thanks for the 'Simple way' to check