This is a regression bug starting in Maple 17 and it seems arising at a rewite of the solve engine associated with the introduction of the subpackage SolveTools:-SemiAlgebraic, see ?updates,Maple17,AdvancedMath . Basically, what happpens is that the original system is rewritten and splited as a pair of systems {2*a+c, 4*c^2-4*c+1, 0 <= a+1/2*c} and {-2*a-c, 4*c^2-4*c+1,a+1/2*c < 0} with inequalities generated out of the square root equation. These systems are solved in turn, the first yielding the expected solution {a = -1/4, b= -1/4, c = 1/2}, and the second one the "solution" {b = -1/2*c}:

> trace(SolveTools:-Engine:-Main):
> trace(SolveTools:-Engine:-Process): 
> trace(SolveTools:-SemiAlgebraic): 
> solve({c^2-c+1/4 = 0, abs(a-b) = 0, sqrt(2*b+c) = 0}); 
{--> enter SolveTools:-Engine:-Main, args = {(2*b+c)^(1/2) = 0, c^2-c+1/4 = 0,
abs(a-b) = 0}, {}, {a, b, c}
...
{--> enter SolveTools:-Engine:-Process, args = [[{(2*b+c)^(1/2) = 0, c^2-c+1/4
= 0, abs(a-b) = 0}, {}, {a, b, c}, {}, true, false, 1, {a, b, c}]], initial
...
{--> enter SolveTools:-SemiAlgebraic:-ModuleApply, args = {2*a+c, 4*c^2-4*c+1,
0 <= a+1/2*c}, {a, c}, outputsystem
...
<-- exit SolveTools:-SemiAlgebraic:-ModuleApply (now in Apply) = [[{2*a+c, 4*c^
2-4*c+1, 0 <= a+1/2*c}, {}, {a, c}, [{a = -1/4, c = 1/2}], true, true, 1, {a, c
}]]}
{--> enter SolveTools:-SemiAlgebraic:-ModuleApply, args = {-2*a-c, 4*c^2-4*c+1,
a+1/2*c < 0}, {a, c}, outputsystem
...
<-- exit SolveTools:-SemiAlgebraic:-ModuleApply (now in Apply) = [[{-2*a-c, 4*c
^2-4*c+1, a+1/2*c < 0}, {}, {a, c}, [], true, true, 1, {a, c}]]}
...
<-- exit SolveTools:-Engine:-Process (now in SolveTools:-Engine:-Main) = [[{},
{}, [], [], false, true, 1, []], [{}, {}, [], [], false, true, 1, []], [{}, {},
[], [], false, true, 1, []], [{2*a+c, 4*c^2-4*c+1, 0 <= a+1/2*c}, {}, {a, c}, [
{a = -1/4, b = -1/4, c = 1/2}], true, true, 1, {a, b, c}], [{}, {}, [], [], 
false, true, 1, []], [{}, {}, [], [], false, true, 1, []], [{}, {}, [], [], 
false, true, 1, []], [{-2*a-c, 4*c^2-4*c+1, a+1/2*c < 0}, {}, {a, c}, [{b = -1/
2*c}], true, true, 1, {a, b, c}]]}
...
<-- exit SolveTools:-Engine:-Main (now in solve) = [{b = -1/2*c}, {a = -1/4, b
= -1/4, c = 1/2}]}
                           {a = a, b = - c/2, c = c}

Then, as Preben has described already, only the more "general" solution is kept. May be that there are several bugs here. One, I think, is generating the inequality a+1/2*c < 0 from (2*b+c)^(1/2) = 0 and abs(a-b) = 0. A second one is about the criterion for selecting solution candidates. And a third one is "deducing" a=a and c=c from -2*a-c=0 and a+1/2*c < 0.

Yes, this functionality seems working since Maple 14, see ?updates,Maple14,de section "Exact solutions for PDEs subject to boundary conditions".

A partial explanation for this strange behaviour is that limit receives a piecewise expression with value erf(1/2*Pi*2^(1/2)) for x>1, namely:

> limit(piecewise(x <= -1,0,x <= 1,-erf(1/2*2^(1/2)*arccos(x))+
erf(1/2*Pi*2^(1/2)),1 < x,erf(1/2*Pi*2^(1/2))), x = infinity);
                                          1/2
                                      Pi 2
                                  erf(-------)
                                         2

So, it may be an issue with the domain of the inverse trig function (arccos).

Some antecedents on the spacecurve issue reported here:

Spacecurve command does not work

spacecurve not working on Maple 17/18

@Carl Love 

Actually there is a specific bug in the integration code, namely in IntegrationTools:-Indefinite:-Main line 27. The integral is computed internally, but then a wrong check for a result with eval makes it discard that result and return instead the integral unevaluated:

> stopat(IntegrationTools:-Indefinite:-Main,27):
> int(eval(diff(f(x), x), x= -1), t);
eval(diff(f(x),x),{x = -1})*t
IntegrationTools:-Indefinite:-Main:
  27*  if answer = FAIL or has(answer,'eval') then
         ...
       end if;
DBG> answer
eval(diff(f(x),x),{x = -1})*t
IntegrationTools:-Indefinite:-Main:
  27*  if answer = FAIL or has(answer,'eval') then
         ...
       end if;
DBG> into
eval(diff(f(x),x),{x = -1})*t
IntegrationTools:-Indefinite:-Main:
  28     answer := ('int')(ff,zz)
DBG> quit

See this thread (this other one may also be relevant)

You may try something like:

> map(u->subsop([1,0]=D(op([1,0],u)),u),x(0)=~0); 
                                 [D(x1)(0) = 0]
                                 [            ]
                                 [D(x2)(0) = 0]

See e.g. this thread.

You can try veiling the coefficients of x, like:

> with(LargeExpressions):
> ex:=(sinh(w) + ln(w))*x:
> collect(ex,x,Veil[c]);
                                     c[1] x

These are MathML tags, see e.g. here. Clearly, MathML is used internally by the MapleSim interface and they are exposed here because of a bug.

There is a command already for splitting integrals that you may try:

> evalindets(Eq,specfunc(Int),x->IntegrationTools:-Split(x,u));
          u                1/3              u                2/3
         /                /                /                /
        |                |                |                |
     4  |   f(x) dx + 4  |     f(x) dx +  |   x f(x) dx +  |     x f(x) dx
        |                |                |                |
       /                /                /                /
         0                u                0                u

And then you can flip limits in the integrals where u is the lower limit:

> evalindets(%,And(specfunc(Int),satisfies(x->type(op([2,2,1],x),identical(u)))),
IntegrationTools:-Flip);
           u                u               u                u
          /                /               /                /
         |                |               |                |
      4  |   f(x) dx - 4  |    f(x) dx +  |   x f(x) dx -  |    x f(x) dx
         |                |               |                |
        /                /               /                /
          0                1/3             0                2/3

Indeed, it would be desirable that it could be done in a single simple step by means of applyrule as you wanted originally, but sadly the PatternMatching package has many bugs that I have reported years ago and were not fixed yet.

Except for possible Mac specifics, the startup page is the file data/Start.mw under the Maple installation directory. And most, if not all, the linked documents under it live (presumably) in the help database file lib/maple.help . Execute, e.g. ?Start,Tools .  

Note, that this behavior arises actually from the hardcoded normalization that the procedure exp makes for some "simple" arguments, which can be inspected. The relevant section is:

> showstat(exp,7..14);
exp := proc(x::algebraic)
local res, i, t, q, n, f, r;
       ...
   7     res := `@@`(ln,op([0, 2],x)-1)(op(x))
       elif type(x,'`*`') and type(-I*x/Pi,'rational') then
   8     i := -I*x/Pi;
   9     if 1 < i or i <= -1 then
  10       t := trunc(i);
  11       t := t+irem(t,2);exp
  12       res := exp(I*(i-t)*Pi)
         elif type(6*i,'integer') or type(4*i,'integer') then
  13       res := cos(-I*x)+I*sin(-I*x)
         else
  14       res := ('exp')(x)
         end if
       ...
end proc

Basically, if the denominator is a multiple of 4 or 6 evaluate in terms of cos and sin (and then it depends on how they evaluate). So, pure exponential or mixed form results may arise:

> term([1,2,3,4,5],1); 
    1, 2 exp(-2/5 I Pi), 3 exp(-4/5 I Pi), 4 exp(4/5 I Pi), 5 exp(2/5 I Pi)

> term([1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16],1); 
                        1/2
                     3 2             1/2
1, 2 exp(-1/8 I Pi), ------ - 3/2 I 2   , 4 exp(-3/8 I Pi), -5 I,
                       2
...

In my opinion, in place of this hardcoded, somewhat arbitrary behavior, a configurable uniform behavior should be available to the user. In the mean time, another posibility is hacking the code of exp, disabling this undesirable branch of the conditional.

And yet, one more posibility is inertizing exp, like:

> term := proc(lst,k::integer)
>     local n;
>     n := nops(lst);     
>     seq(lst[m+1]*%exp(-I * 2*Pi/n *(k*m)),m=0..n-1);
> end proc;
> term([1,2,3],1); 
                 %exp(0), 2 %exp(-2/3 I Pi), 3 %exp(-4/3 I Pi)

Note, however, that here all the normalizing transformations are disabled, including exp(0) ==> 1.

Obviously it is a bug as a[1][2] is as valid a name as a[1]. Compare both cases, a problem occurs in `PD/convert/compseq`:

> infolevel[D]:=5:
> f := x -> a[1][2]*x;    # the double index on a[][] is intended
                              f := x -> a[1][2] x
> D(f)(x);
D:   Applying    D   to    f
D:   Either a name or a procedure
D:   Looking for   D/f
D:   Looking for   diff/f
D:   No pre-defined rules
PD/convert/compseq:   unable to differentiate subscript   a[1]
                                    D(f)(x)
> g := x -> a[1]*x;    
                                g := x -> a[1] x
> D(g)(x);
D:   Applying    D   to    g
D:   Either a name or a procedure
D:   Looking for   D/g
D:   Looking for   diff/g
D:   No pre-defined rules
                                      a[1]

It is trying a factorized pattern like u(x,t)=_F1(x)*_F2(t) but fails, producing a general solution as products of exponentials. It seems like a more "refined" pattern is needed for match as here:

> pdsolve([pde,bc],HINT=x*f(t));
                                  u(x, t) = x
> pdsolve([pde,bc],HINT=g(x));
                                  u(x, t) = x

As pdsolve tries diverse heuristics, and the user can provide hints, may be that the class of equations "too hard" is not so well defined.