The following code works on my simple test, but I don't know if it will work with more complicated code. If it doesn't, please post some example code of the sort that you want to work with.
Here's the code:
Some stuff which \pause extends over \pause several slides \pause
\draw[use as bounding box] (0,0) rectangle (3,3);
\draw<1-> (0,0) -- (3,3);
\draw<.(1)> (3,0) -- (0,3);
\draw<3> (0,1) -- (3,1);
\draw<4> (1,0) -- (1,3);
Some stuff which \pause extends over \pause several slides
Now for the explanation. We define a new environment,
inframe, which takes one mandatory argument, a number (and an optional argument, also a number - see below). What happens is that in the environment, the slide number is set to that number (the mandatory one) which means that in the environment, overlay specifications are processed as if the slide number was the given one, not the real one.
This does, however, cause a few problems because if
beamer thinks that it is on slide 2 and it encounters an overlay specification for, say, slide
4 then it says to itself "I have to do another frame". Since on every slide, we confuse it into thinking it is on, say, slide 2 then every time around it thinks "I'm going to have to do another run, here". So to avoid an endless loop, we temporarily disable the "Do I do another frame?" check. That's the
anotherslide bits. The other problem that this causes (that I know of - there may be more) is that specifications such as
+ do funny things to a counter called
beamerpauses. Within the environment, we want these to work as they should, but then we want to forget these changes when we go back to the normal frame. So we save the value of
beamerpauses at the start and reset it at the end. The optional argument allows us to specify a "start point" for
beamerpauses which allows us to imagine that things like
+ start at something other than 1.
Warning: When testing, be ready to kill the TeX process as it is easy to get into infinite loops.