Why is there a /base/default/ layout and a /default/default layout?

Question

Why is there a /base/default/ layout and a /default/default layout? This seems confusing and redundant.

Answer 1

In short default/default is legacy from < 1.4CE where it was the original base package. Magento core themes ship in default package still - so it is not necessarily deprecated so much as it is legacy.

Because default/default can be overwritten during upgrades of CE it is not advisable that you place files here - but plugins attempting to be backwardly compatible with < 1.3 may intentionally place files here instead of base/default.

---

_{Source: http://www.magentocommerce.com/knowledge-base/entry/magentos-theme-hierarchy#3.2}

Answer 2

I found an even better answer on the official Magento wiki. (It's from 2012, so I am not sure if any of the information is outdated -- but it seems to be applicable to 1.8.1 from what I can tell.) While I highly recommend that you read it in full (click the bold link), let me summarize it below.

What is /base all about?

/base/default was introduced in CE 1.4 and EE 1.8 to consolidate all the app-logic-type front-end functionality into a single codebase that you should never edit. It has the same directory structure as a design package with a default theme, but it's missing some key CSS files so they don't recommend you to have it as your only design package and theme.

A great analogy would be to say that /base is to /design/frontend what /core is to /code. You're not supposed to modify the files inside /base. Instead you're supposed to extend its functionality in your own custom design package, which Magento will look inside of first before it falls back on /base/default -- first it will look in /design/frontend/{custompackagename}/{customthemename}, then it fall back on /design/frontend/{custompackagename}/default/, and lastly it will fall back on /design/frontend/base/default.

Really, it should just be thought of as /base — the /default subdirectory is only there because the Magento fallback system completes its journey through each design package in its /default theme. To be clear, a design package is a subdirectory within /design/frontend, and theme is a subdirectory within a design package. When Magento looks through a design package, whether it's /base or /{custompackagename}, the /default theme will always be the last place Magento will look.

Therefore, since the primary purpose of /base is to serve as the final point in the fallback system, according to that purpose it will never have any other theme than /base/default.

Why is there a /default then?

So then why is there still a /design/frontend/default/default? And why isn't there a /design/adminhtml/base/default? To be honest I don't know the answer to the second question. But let me try to answer the first.

Forgetting legacy compatibility etc., I feel it might be much easier to understand if it were called /generic/default instead of /default/default. So for the purposes of this discussion I will refer to /app/design/frontend/default/ and /app/skin/frontend/default/ collectively as the "generic design package". I'll be referring to everything inside those directories as if they were called /app/design/frontend/generic and /app/skin/frontend/generic. Since (least in the case of frontend) Magento's fallback system no longer falls back to /app/design/frontend/default/, I feel that continuing to call it "default" is confusing since that word implies something is part of the fallback chain, but the generic design package is no longer part of the fallback chain as of the introduction of /base. Therefore, calling it the "generic design package" instead of the "default design package" alleviates this confusion by telling us that yes, it's just the set of generic themes that comes with Magento for free, without implying it's part of the fallback chain. :D

Carrying on then: the generic design package has a default theme and several non-default themes inside: /blank, /iphone, and /modern. If a non-default theme is active then its files will override anything in the default theme, but no matter which non-default theme is active, any parts of the generic package's default theme that haven't been overridden by the non-default theme still get run, and further they will override anything in /base/default. Finally any non-overridden parts of /base/default get run.

However, critically, no part of the generic design package will ever get run if you are using a custom design package. The fallback system goes straight from {customdesignpackage}/{customthemename} to {customdesignpackage}/default to base/default. (Unless I'm not understanding this correctly; please correct me if I'm wrong.)

That being said, deleting the generic design package entirely without having a custom design package in place would be unwise since the generic design package has some skin elements that are still necessary.