In case of problems one should try to plot the function (here: x^2+y^2-1) to get some feeling

In a "strict" interpretation the assumption does not make much sense for me: in v=0 one asks for the Taylor series in the (standard) branch cut. While for my understanding a Taylor series is for an analytic function.

> taylor(sqrt(x-1), x, 2);
Error, does not have a taylor expansion, try series()

> series(sqrt(x-1), x, 2);

                                                           2
         -I csgn((x - 1) I) + 1/2 I csgn((x - 1) I) x + O(x )

> taylor(sqrt(x-1), x, 2) assuming -1/2<x,x<1/2;;

                                          2
                         I - 1/2 I x + O(x )

> mtaylor(sqrt(x-1), x, 2) assuming -1/2<x,x<1/2;
Error, (in assuming) when calling 'mtaylor'. Received: 'does not have a Taylor expansion'

> MultiSeries:-series(sqrt(x-1), x, 2);

                                          2
                         I - 1/2 I x + O(x )

I think it evaluates first in z=0 and then starts the summation:

eval(z^k, z=0);
                                  0
eval(z^k, [z=0,k=0]);
                                  1

Hm ... my 'feeling' says: this is like filling the 2*2 matrix A with arbitrary real polynomials (and may be their constants are complex).

I doubt that this results in usable solutions for A*x= 0, even if x would be a constant vector.

This is (for dim = 2) like asking for a general formula (take degrees = 0).

What is the result of MuPad (even if it may treat only the generic case and may ignore parameters for the polynomials, Maple may behave similar)?

Sometimes I use the following procedure:

split_for_print:=proc(expr, len)
 # expr = some Maple expression
 # len  = length to split with line breaks
 local L,s,j;
 s:=convert(expr, string);
 L:=[StringTools:-LengthSplit(s, len)];
 for j from 1 to nops(L) do
   if j = nops(L) then printf("%s", L[-1]) 
   else printf("%s\\\n", L[j]); 
   end if;
 end do:
end proc;

# usage
evalf[119](Pi):
split_for_print(%, 40);

 3.14159265358979323846264338327950288419\
 7169399375105820974944592307816406286208\
 9986280348253421170679821480865132823066

I can copy + paste it through a text editor (enforcing to forget
formatting) into a Maple sheet as well (classic interface)

@abcd do it "slowly" since clicking again removes it

If 0 < m and m even is a condition then you start in m=2 (and proceed in steps of 2). Perhaps you re-formulate you taslkin mathematical terms first to see what you want?

You can convert to hypergeometric or Bessel functions to avoid the bug

Int(WhittakerW(0, a, x)*WhittakerW(0, b, x), x); 
convert(%, hypergeom); simplify(%);
value(%);

PS: the title is a bit misleading

I never liked it that solve needs that additional option, so I often use RootOf and allvalues on its result.

@Carl Love 

Could there be a way through convert / relation (and back) to handle it?

@vv 

I am never sure whether Maple means the same integer in its results like [x = -Pi*_Z1, y = Pi*_Z1], though here for +-1 etc it is the desired one, giving -1 for your task 3.

Using Markiyan's reformulation on can compute it in terms of dilog
and log. I do not want to go into dilog to prove that it is Pi^2/16
(I do not have the needed identities at hand, may be later on).

 2*Int(arcsinh(cosh(x))-x,x = 0 .. infinity);
 
 IntegrationTools:-Change(%, x = -1/2*ln(t), t): 
 convert(%, expln): simplify(%): combine(%);
 # already that allows painless numerical integration
 
 IntegrationTools:-Change(%, t = r*(r-1)/(r+1)):
 simplify(%): combine(%, ln); #collect(%, signum);
 
 #convert(%, piecewise, r):
 #simplify(%)  assuming 0<r, r < 1+sqrt(2);
 #combine(%, ln);
 
 value(%); lprint(%);  
 evalf(%);

   -1/6*Pi^2-1/2*ln(1+2^(1/2))*ln(2)-1/2*ln(1+2^(1/2))^2-
     dilog(2+2^(1/2))-dilog(1+2^(1/2))+2*dilog(2^(1/2))+
     2*dilog(2^(1/2)-1)+ln(2)*ln(2^(1/2)-1)+ln(2^(1/2)-1)^2

                           1.23370055013614

Edited:

the most simple expression I get has two dilogs (splitting the integral in the sign change),

-1/12*Pi^2-dilog(1+2^(1/2))-dilog(2+2^(1/2))+(-1/2*ln(2)-1/2*ln(1+2^(1/2)))*ln(1+2^(1/2))

I had similar problems, also for formattings. It seems this site desires am almost blindly open browser.

For such cases I either use IE or a portable FF. Being visible for any kind of tracking which I dislike a lot.

Yes, the bug is fixed in Version 2016 (also, if one apllies it to convert(f Heaviside) )

The result is min(0,r1,r2,r3) where the r_i are of magnitude ~ 10 as we
know using high precision.

Looking at numer, denom for the r_i and magnitude of the largest resp.
smallest summand using "op" and 

  max(ilog10(summand)) - min(ilog10(summand))

one gets

  [[49, 1014], [38, 1209], [41, 1238]]

So I would take Digits = 65 for the numer, Digits = 1265 for the denom
to get ~ 15 correct decimals (one would not need it to see that the r_i
are strictly greater then 0).

This also indicates (?) that the result in terms of RootOf is not per se
the problem. But the hybrid method may fail for usual/reasonable precision.

Just for fun (?) after a longer fight I think that r1 ( = r2 = r3 ?) is

  RootOf(Poly, y, index=2))

  Poly := 7119140625*y^12
     +3099228906087451818800000 *y^11
     +64962318519685037678473211520000 *y^10
     -260950408703896884967024736600064 *y^9
     +6364235442851780831217579634720768 *y^8
     -47520302726101144045615692046663680 *y^7
     +185748590355649068374697586320211968 *y^6
     -2602177247199932977791422875173912576 *y^5
     +2583311691338714324774209167072165888 *y^4
     -41308047787286208908486931594520559616 *y^3
     +37137764247844996460953224240357703680 *y^2
     -34702649729686434242293422381764444160 *y
     +2028612116589282153287052920195383296

independend of set Digits.