I think we should take this bug off the beta 2 list.  Two reasons:

1) To my knowledge, it's not resulting in user discoverable error.

2) We may decide it's already doing the right thing, and whoever calls it needs
to be careful to call it on a bundle, not an instance inside a bundle.

This behaviour does lead to a bug in ContentSectionServlet's Item-URL cache
right now.  com.arsdigita.cms.ContentSectionServlet lines 228-229 cache the
result of an ItemResolver.getItem() call.  Justin, is the right thing:
-ItemResolver should return a ContentBundle
-ContentSectionServlet should get the ContentBundle from the item returned by
the ItemResolver
-ContentItem.getPath() should work properly from a ContentItem that isn't a bundle

I'm not sure what is the right behaviour.

Bryan, I'm inclined to say that your second option is the correct behavior,
since the bundle, not any contained item, is really the locus of dispatch.  It
follows, if you think of it the way I do, that:

a) A bundle's path is important; it is the leaf node of the tree of dispatchable
things (where "dispatch" here refers to the long-standing method of CMS "item"
dispatch, not the newer language resolution that occurs after the bundle itself
is resolved).

b) A language instance's path is *not* important (basically junk) since it is
not used for dispatch.

Of course, I don't feel my views on this are necessarily widely held, so I feel
some trepidation in making proclamations.  Any comments?

We discussed at the bug roundup and decided to move this to rc0.

This is what is causing bug 102894 but I don't necessarily think it is
blocking....102894 is just an example of what can happen if the developer is not
aware that the bundle is also included and it shows how any existing code will work.