@Bendesarts 

This is certainly possible using directly components (instead of Explore which uses such components internally).
Of course using Explore is easier but a little limited in this case; I would switch to components only if the present simple solution is definitely inacceptable.

@Carl Love 
You mean of course
evalf(Int(x-> h(g(x)), 1..2));

@Bachatero 

It would not be difficult to write a procedure `combine/product`  to transform e.g.

product(a^p[i]*b[i],i=1..n);
into
a^sum(p[i],i=1..n)*product(b[i],i=1..n);
but I am not sure whether it's worth it. Note that actually the second expression is longer.

What has to do ec1 with your question?

@Markiyan Hirnyk 

restart;
Order:=15:
ec:=sin(x+y)+sin(x)-y:
ec0:=simplify(subs(x=z+Pi,ec)):
solve(series(ec0,y),y):
R:=subs(z=x-Pi,%);

   R := -x+Pi+(1/12)*(x-Pi)^3-(1/240)*(x-Pi)^5+(1/10080)*(x-Pi)^7+(17/362880)*(x-Pi)^9-(1153/159667200)*(x-Pi)^11+(13297/24908083200)*(x-Pi)^13+O((x-Pi)^15)

series( sin(x+R)+sin(x)-R, x=Pi ); #check
    O((x-Pi)^15)

@Markiyan Hirnyk 

@Carl Love 

# A simple proc, un-optimized, un-tested that
# should return the RootOfs with multiplicity >= m.
restart;
mindets:=proc(e,m)
local ss,ii,fs;

   fs := proc(u)   
   if nops([StringTools:-SearchAll(convert(u,string),ss)])   
      >=m then true else false
   fi
   end;

ss:=convert(e,string);
ii:=indets(e,RootOf);
select(fs,ii)
end:

e:= 10 + sin(RootOf(a^5-5)+RootOf(a^9-9)+RootOf(c^3-3)+sqrt(RootOf(z^3-3)));
mindets(e,2);

@Carl Love 

This was my first thought too. But sometimes it is better to keep some RootOfs.
Or, make the alias only if they repeat.

Probably the best solution would be an interactive program with suggested sub-expressions to be "covered" and the possibility to use your own names for them.

@Carl Love 

Sorry, I simply forgot to do it, not because I do not appreciate your professional contribution. I really do; and thank you, of course!

V.A.

@Carl Love 

Interesting approach.
It should also consider situations like

eval(g(x),x=2*x);

where it fails.

@ecterrab 

My point is that in this situation eval acts blindly just like subs (in other situations).
After all, eval already does a "corruption of the programming language" when executing eval(int(f(x),x),x=1);
As I said, it is not a big deal, but the user must be informed about it.

@Kitonum 

Nice, vote up!

But what would be the simplest workaround for g(x) ?
I mean simpler than eval(g(_x), _x=x)

@ecterrab 

Correct? For g(x),  I would expect e.g.

int(f(_x+x), _x=x..2*x):

Edit. I know that in int, the dummy variable is not local to int.
But mathematically, g has nothing to do with x, so, g(x) should be as above.
I did not insert "bug" as a keyword, because I don't see this as a bug,
but mathematically it's incorrect.

P.S. I also know that the "correct" g should be
g:= proc(a) local x; int(f(x+a),x=a..2*a) end:

@Markiyan Hirnyk 

This is an excellent idea!
It makes possible to
1. Prove easily the theorem
2. Obtain easily animations even for n>50 circles.

V.A.

@Axel Vogt 

I think that sqrt is not important (exept probably for the initial "division by 0" because sqrt in not differentiable at 0).

method=Laplace works because Int is a convolution.

@Axel Vogt 

Do you mean y(s)=sqrt(s)  and the corresponding F(s)?

I just took it randomly. intsolve solves it wrt invlaplace but is not smart enough to use linearity and retrive sqrt(s).