@Markiyan Hirnyk 

solve(eval([p(z),q(z),r(z)],s[14])); # NULL

or

pqr:=eval([p(z),q(z),r(z)],s[14]):
Groebner[IsProper](pqr);   #false

The situations are not similar, here we have a symbolic solution + numerical confirmation.
This should be an acceptable solution by any standard!

Or, ... by hand.

 (Edited)

@Markiyan Hirnyk 

Then any result of a Maple solve command is "unbased".

We have found symbolically the example, solve agrees, numerical verification ok.
The last step would be to verify by hand. It will take a few weeks, but let's go! 

Edit.

PS. You see, it's another example of your multi-"unjustified objections"

@Markiyan Hirnyk 

The code was implicit.

c:=1:
p:=x->a*x^11+b*x^4+c: q:=x->b*x^11+c*x^4+a: r:=x->c*x^11+a*x^4+b:
s:=solve([p(x),q(x),p(y),r(y)]):
evalf(s[14]);  #the provided counterexample

@Markiyan Hirnyk 

Actually the real case results from the provided hint.
According to the Maple solution, there are only a finite number of polynomials
(one of them was posted) for which the conclusion fails; all of them have of course complex a,b,c.

The problem can be simplified as in the first russian solution (with A=a^2-bc etc)
and the exceptions have a smaller length for A,B,C.
[That was my first approach but I had no patience for all the cases when I gave the hint].

Note also that Maple verifies that a common root for p,q,r does not exist for a,b,c
in the provided example:
solve gives () and this can be also seen looking at the solutions (x,y,a,b) given by solve for
the system p(x)=q(x)=0=p(y)=r(y).

@Markiyan Hirnyk 

As I have mentioned, a,b,c are very large. If you relly want to see them, here they are:

c =1

a =

b =

P.S. What is the source of the problem? It was interesting.

@Markiyan Hirnyk 

I am also an old PhD and my students would appreciate this hint (<> proof).

A reason for not giving the whole solution is that several times in the past you started an endless sequence of unjustified objections (about a correct statement) and today I am not in the mood to answer them.

@Markiyan Hirnyk 

p,q,r are obviously your polynomials, not mine :-)
and the statement is true (for them).

I think that the hint is enough.

@Kitonum 

piecewise is much more reliable in such contexts.
Replacing `if` with piecewise gives the expected result.

@Kitonum 

evalf fails even for more obvious examples such as

f:=unapply(`if`(n<10^10, 0, 10^10), n);

But adopting this point of view, we should analyse each and every approximation obtained by Maple. Practically this is done only if the result is critical, or if our intuition suspects that something went wrong.

@shahid 

Do yo have an ODE which cannot be solved using the buit-in commands?

The initial version was

A3_2015:=proc(n::posint)
local i;
if type(n,even) then return 0 fi;
add(igcd(i,n),i=1..n);
end:

I'll stop here.

It was a minor edit, ''2''^ was inserted and it was mentioned later.

add(igcd(i, 2014), i = 1 .. 2014);
is never executed. I do not understand your continuous objections.

It should be obvious that A3_2015 computes the product, not its log2 (so that it returns 0 if n is even).

@Markiyan Hirnyk 

13725 is(was) the exponent (power 2) of the answer. I have added the basis to avoid confusion.

@Markiyan Hirnyk 

So, 2015-A3 cannot be solved (as expected) by brute force. One needs:

A3_2015:=proc(n::posint)
local i;
if type(n,even) then return 0 fi;
''2''^add(igcd(i,n),i=1..n);
end:

A3_2015(2015);

(Of course, Maple has a small contribution here.)