This is a conceptual question (I really think there should be a seperate topic just for conceptual).

I kind of think there are too many topics ... it's really hard to track new posts, especially when a lot of things get posted in multiple topics :)

Anyway, you're pretty much spot on about content. The default Orchard installation (or the Recipe in 1.1) creates some content types for you (Page and List obviously; but there are other ones hidden away such as User). You are free to customise these content
types in any way you want. What makes a Page actually page-like are the Routable and Body parts.

Blogs and Blog Posts are also just content types. A module can define its own content types and compose them out of any available parts. There are two special parts that the Blog module comes with: BlogPart and BlogPostPart.

The reason you can't create your own Blog content type from scratch is simply because the BlogPart and BlogPostPart aren't available in the list of attachable parts. That's normally done in Migrations.cs where you have a command like this:

However because the blog module is lacking those lines, you can't "roll your own". But you can still customise Blog and BlogPost in the Content Types section of the Dashboard, you'll just notice you can't remove the Blog or Blog Post parts.

Why do Pages show in the New menu and get listed in Content Items, whereas Blogs don't? I think it has to do with this from Migrations.cs in Orchard.Pages module:

I think it's the .Creatable() command (and nothing else) that differentiates it from blogs and blog posts.

I'm not sure of all the reasons for doing it this way. In part I think it's because the Blog module comes with its own admin UI and it'd be redundant to have two ways of managing stuff. Also the Content Items screen would quickly get out of control if 10s
or 100s of blog posts were there mixed in with all your other content. But I can't see any real reason to prevent custom types of blog and blog post from being created. Maybe you could experiment with making those parts attachable and see what happens? ...Not
on a production site of course, in case things blow up :)

Blogs were developed before we had the full type system. It’s been our intention for quite some time to unify blogs and posts with lists and items, but we have not found the time to do it yet. It will happen at
some point though.

Blogs were developed before we had the full type system. It’s been our intention for quite some time to unify blogs and posts with lists and items, but we have not found the time to do it yet. It will happen at some point
though.

ALLcontent types ARE EQUAL, BUT
SOMEcontent types ARE MORE EQUAL THAN OTHERS.

Currently, there is a Container/Containables system which allows you to create a content type that can
contain another type.

Basically, that's what Blogs are doing - a Blog contains BlogPosts.

But because the Blogs module was created prior to the Containers system, it uses its own mechanism for linking blogs to blog posts, it doesn't go through the Containers route.

What Bertrand and the workitem are saying, is that the Blogs module is due to be refactored so that it
does use the Containers system. Doubtless this will also require some refactoring of the Containers to support some of the additional functionality that Blogs currently have. This will likely then mean that you could roll your own Content Type that
behaves to all intents and purposes just like a Blog.

It will still be possible for a module to provide a Content Type that you
cannot create through the "New" menu. There are a lot of reasons why module authors might want to enforce this (although in general the best practice is to provide parts that can be reused anywhere - it's sometimes just going to be harder to do things
that way). Work item #16780 is just bringing one module more in line with the composability architecture.

In theory you could add Routable to a Widget. I don't know what this would do; maybe the widget would display in the standard Content zone on that page. Or maybe the world would explode!

Yes you can create content types without Routable. Comments are one built-in example, and I've seen other modules use non-routable content types.

Anything with Container (not Containable) can be used in the Container widget. They don't have to be Routable.

Routable just describes the process of mapping a URL to a particular content item. Since widgets use a different layer-based method of visibility, they don't have anything to do with routes.

Yes - me bad ;-) I meant to type Route.

I don't understand "In theory you could add Routable to a Widget. I don't know what this would do; maybe the widget would display in the standard Content zone on that page."

The part I am hung up on is "that page" Isn't a
Page in Orchard just one of the many Content Types?
Widgets get added to Zones, not Content Types, correct?

"Anything with Container (not Containable) can be used in the Container widget." Isn't this backwards? The
Widget or Content Type would have the Container Part (Like the
List Content Type that ships with Orchard). The group of "things" being included in the summary need to have the
Containable Part.

- When I said page just then I meant webpage or URL. I think the Page content type could be better renamed to Article to avoid confusion. Widgets get applied to Zones based on Layer rules. But there are
other ways to push things to zones; and one thing Routable does is push content to the Content Zone. So what I was saying was that if you applied Routable to a Widget, then on that Url you might get that widget in the Content Zone.

- The Container Widget is a widget for displaying Containers. Just like the Html widget is a widget for displaying Html. This makes sense when you think about it.

I'm only describing what I find out as I experiment with these different parts. Do the same; experiment with all this stuff and see what it does.