<p>For example:</p>

<pre><code>public class A : A.B
{
    public class B { }
}
</code></pre>

<p>Which generates this error from the compiler:</p>

<blockquote>
  <p>Circular base class dependency
  involving 'A' and 'A.B'</p>
</blockquote>

<p>I always figured a nested class behaved just like a regular class except with special rules concerning accessing the outer class's private members, but I guess there's some implicit inheritance occurring between the two classes?</p>

There's no implicit inheritance involved as far as I can tell. I would have expected this to be okay - although I can imagine weirdness if A and B were generic.
It's specified in section 10.1.4 of the spec:
When a class B derives from a class A,
  it is a compile-time error for A to
  depend on B. A class directly depends
  on its direct base class (if any) and
directly depends on the class within
  which it is immediately nested
(if
  any). Given this definition, the
  complete set of classes upon which a
  class depends is the transitive
  closure of the directly depends on
  relationship.
I've highlighted the relevant section.
That explains why the compiler is rejecting it, but not why the language prohibits it. I wonder if there's a CLI restriction...
EDIT: Okay, I've had a response from Eric Lippert. Basically, it would be technically possible (there's nothing in the CLI to prohibit it), but:
Allowing it would be difficult in the compiler, invalidating various current assumptions around ordering and cycles
It's a pretty odd design decision which is easier to prohibit than to support
It was also noted on the email thread that it would make this kind of thing valid:
```
```
A.B x = new A.B.B.B.B.B.B.B.B.B.B.B.B();
```
```
... but that would already (as noted by Tinister) be valid if B derived from A.
Nesting + inheritance = oddness...