@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

What you are describing sounds very familiar to me (and I think I have even posted something here, that I cannot find straight away). It is most likely not a bug but related to Windows (7 and 10) and your personal setup.

A few questions:

What happens if you wait (for me Maple sometimes started after a few minutes)?

Any recent changes on your computer or network configuration?

Does Maple start always from the start menu (i.e. without double click on a file)

It is super annoying and not reproducible. For me it disappeared as it appeared several times over the past 5 years. I remember that this effect was more pronounced after a fresh system start-up. Also changing/ connecting/disconnecting networks seemed toplay a role.

PS.:My biggest suspicion at the moment is Java in combination with Windows.

@ That's what I get

An example would be helpfull.

Maple uses the method exact to solve the ode. Slighty better results can be obtained this way

factor(ode);
%*denom(lhs(%));
dsolve(%)

This way the first 5 solutions can be identified as the roots of the first term encricled in red. The sixth solution (in yellow) is now what we would expect since a different method (separable) was applied

Your original sixth solution is implicit which can be made explicit this way

simplify(isolate(diff(sol[6],x),diff(y(x),x)));dsolve(%)

I can't tell why Maple returns an implicit solution

@nm 

Interesting design decision that seems to save memory space, as no power statements are required in arithmetic expressions.

dismantle(a^b);

POWER(3)
   NAME(4): a
   NAME(4): b

@jganding 

This makes it a bit more generic

expr :=1* Unit('h');
evalf(convert(expr, 'unit_free'))*indets(expr, specfunc(Units:-Unit))[];