I have problems with _root and _parents:

I have a MC on the maintimeline - in that MC there is another MC that i would like to get to from a button on the maintimeline.

use your movieclip instance names

If I have an mc named top_mc, inside it I have one named middle_mc, and I
would like middle_mc to play from frame 2, I would reference it by the
following:

_level0.top_mc.middle_mc.gotoAndPlay(2);

You may also use _root.top_mc.middle_mc.gotoAndPlay(2); if only using one
level, but it's good practice to reference the level you want (in theis case
_level0) instead.

will you take a look at my fla file:

rectangle2_mc is on rectangle1_mc which is on the main time line. button_btn
is also on the main timeline. This code will toggle the rectangle2_mc on and
off.

button_btn.onRelease=function()
{

_level0.rectangle1_mc.rectangle2_mc._visible=_level0.rectangle1_mc.rectangle2_m
c._visible?false:true;
}

I wouldn't say using _level0 to access anything is good practice. You should be
using relative paths and if you dont want to then you should be using _root and
then use a _lockroot if you're going to load the SWF into any other files.
Making tons of references to _level0 (and even _root) can be a nightmare when
trying to incorporate SWFs into larger applications. Thats why relative paths
are preferred.

I agree in some areas caskater

Relative paths should be used, but I know I'd much rather use _level0.my_mc
(or _root.my_mc) than _parent._parent._parent._parent._parent.my_mc

I use _level0 because many times people will use levels for loading in swfs
and I'll need to reference a variable on _level0, such as a parsed XML object.
Using _root won't reference that.

I see your point behind using _root if you're piecing together multiple swfs.
I guess I've never had to piece together multiple swfs that were not planned to
be incorporated from the beginning. But, since all the code is on one frame
anyway, doing a simple find/replace _level0 with _root on the offending swf
wouldn't be a nightmare at all.

Different situations, different best practices.