plots[odeplot](dsol, [t, (D@@2)(X[5])(t)], t = 0 .. 5, numpoints = 250);

or

plots[odeplot](dsol, [t, diff(X[5](t), t$2)], t = 0 .. 5, numpoints = 250);

But for <A, B> to work, B would have to be a row Vector, not a column Vector.  If B is a column Vector, you could try

<A, B^%T>

But for <A, B> to work, B would have to be a row Vector, not a column Vector.  If B is a column Vector, you could try

<A, B^%T>

> dsolve(diff(x(t),t) = t/x(t), x(t), implicit);

x(t)^2-t^2-_C1 = 0

 I see the <maple> tag is acting up again: the result should be

x(t)^2-t^2-_C1 = 0

> dsolve(diff(x(t),t) = t/x(t), x(t), implicit);

x(t)^2-t^2-_C1 = 0

 I see the <maple> tag is acting up again: the result should be

x(t)^2-t^2-_C1 = 0

Although the function (call it f) is undefined at that pole (call it p), it appears to map the interval (0,p) onto (0,infinity) and
(p, infinity) onto (-infinity,0).  Thus (if we remove the removable singularity by defining f(0) = 0) it does have an
inverse as a map from [0, p) union (p,infinity)  to the real line.

Although the function (call it f) is undefined at that pole (call it p), it appears to map the interval (0,p) onto (0,infinity) and
(p, infinity) onto (-infinity,0).  Thus (if we remove the removable singularity by defining f(0) = 0) it does have an
inverse as a map from [0, p) union (p,infinity)  to the real line.

You have to understand what implicitplot does.  It doesn't really plot curves where an expression is 0, it plots curves where the expression changes sign.   In this case the expression goes to +infinity on one side of the curve and -infinity on the other. 

And the procedure passed doesn't have to be a named one.

> f1((t -> t^2 + 1), u);

          u^2+1

> f1(proc(t) local i, R; R:= 0; for i from 1 to t do R:= R^2 + 1 end do end proc, 3);

                                  5

 

And the procedure passed doesn't have to be a named one.

> f1((t -> t^2 + 1), u);

          u^2+1

> f1(proc(t) local i, R; R:= 0; for i from 1 to t do R:= R^2 + 1 end do end proc, 3);

                                  5

 

Hmmm, this is interesting.  There seems to be a change in 1d input parsing from Maple 12 to Maple 13.  In Maple 12, 1d input, 3[Sigma] produces that error.  In Maple 13 it is accepted without an error.  Note that the object 3[Sigma] can be produced, even in Maple 12, e.g. by

> subs(a=3, a[Sigma]);

                               3[Sigma]

> parse(convert(%,string));

Error, incorrect syntax in parse: `[` unexpected (3)

Since (presumably) the string representation of a valid Maple object should be accepted by parse, the Maple 13 behaviour is preferable.

Hmmm, this is interesting.  There seems to be a change in 1d input parsing from Maple 12 to Maple 13.  In Maple 12, 1d input, 3[Sigma] produces that error.  In Maple 13 it is accepted without an error.  Note that the object 3[Sigma] can be produced, even in Maple 12, e.g. by

> subs(a=3, a[Sigma]);

                               3[Sigma]

> parse(convert(%,string));

Error, incorrect syntax in parse: `[` unexpected (3)

Since (presumably) the string representation of a valid Maple object should be accepted by parse, the Maple 13 behaviour is preferable.

M[2] doesn't work in Maple 9.5.  M[2,1..-1] and M[1..-1, 2] should work in all Maple versions that have the Matrix type (i.e. Maple 6 and up).

You could also use

> with(LinearAlgebra):
  Row(M,2);
  Column(M,2);

M[2] doesn't work in Maple 9.5.  M[2,1..-1] and M[1..-1, 2] should work in all Maple versions that have the Matrix type (i.e. Maple 6 and up).

You could also use

> with(LinearAlgebra):
  Row(M,2);
  Column(M,2);

But applied is documented: ?type,applied.  What's not documented is the reason for it.  It's not mentioned in the ?updates,Maple9_5 pages, where new features should be introduced.