What is a configuration item?

There are many definitions for (software) configuration management and most of them rely on the term configuration item (CI). In general, the meaning of this term boils down to something like:

An object that is treated as a self contained unit for the purpose of identification and change control [Source]

These are nice words and I think that I understand what the sentence means, but do we understand what a CI is? Are we able to pinpoint all and every CI of a project, and separate the CIs from the objects that are not CIs (but still relevant objects in the project)?

Let's make a side step. Suppose you are going on vacation and you are taking with you a lot of items. Let's replace change control by entertainment, because development's purpose is to make changes while vacations are for fun. Your passport is a self contained unit for the purpose of identification (of you); it is not for entertainment by itself, but it is needed to get to the destination where you will find your entertainment. The maps are also self contained units for the purpose of identification (of the route and the geographic area), and also indirectly linked to the entertainment part. Same for the money you take with you.
But how about your shoes? If you plan to go walking, dancing or playing tennis, you need shoes. But you need different shoes for different activities. So should we consider shoes in general, or should we consider walking shoes separate from tennis shoes? And should we consider left and right shoes as different objects? They are all self contained, and they are all for the purpose of entertainment.
But... are they for the purpose of identification? No? Well yes! The shoes are for the purpose of identifying the contents of your luggage. Without the shoes the luggage would be incomplete. The same for other items in your luggage. Could we define "the contents of your luggage" as one item? Well, yes and no. First of all, your luggage may consist of several suitcases, so the contents needs to be divided. You must be able to identify which items go in which suitcase. Assume you only take with you the items that have a purpose for your holiday, all items are for the purpose of identification (of the content of a suitcase) and entertainment. So luggage may be one CI, but also multiple CI depending on how you look at it.
Now, is "luggage" a CI, or is "the content of a suitcase" a CI, or are they both? Are the suitcases themselves CIs? Are the "set of suitcases" that you hand-off as cargo at check-in at the airport a CI? Are tennis shoes a CI different from walking shoes, or is "the set of shoe pairs" a CI? Do tennis socks belong to the tennis shoes and form a single CI together, or are they separate CIs? Maybe you wear them only in tennis shoes, or maybe you wear them in your walking shoes too. And how does wearing them under different circumstances in different combinations require tennis socks to be separate CIs? They do not contribute to the entertainment separate from the shoes, do they?

You may argue that a vacation does not "produce" concrete items like a development project, it only "consumes" so you cannot compare vacation with development projects. Well, that's not entirely true. A vacation does not produce a lot items, but when the vacation is over you do take home items that you did not take on holiday with you, such as photos, souvenirs, presents for friends and family, etcetera. You add items to your luggage, which may be considered a way of producing them. These extra items identify the content of your luggage on the way back.
Note that the CI "content of your luggage" changes over time, not only by adding items but also by dividing your items differently over your suitcases.
You do not want forget items that are of value to you when you go home. When you do, you'll be stuck with some bad memories and that spoils the purpose of your vacation (i.e. entertainment).

As you can see, configuration identification for a vacation is not simple. But nobody really worries about it, nobody talks about it and everybody does it. The only things you hear are things like "Don't forget your hairspray!", "Watch for your passport and tickets" or "Which way is it?". Nobody worries about reviewing and approving plans, schedules, routes, documents or luggage, and nobody really worries the risk of forgetting some items or losing them as long as you have your risk mitigation measures in place (a credit card, a mobile phone, insurrance, friends travelling with you). Even without formally organizing it, everything is set up with common understand and agreement.
So although configuration identification (or CM in general) for a vacation is non-trivial, not simple but very important for a successful vacation, it is never a big issue.

Now let's go back to a development project. In fact, configuration identification for a development project is similarly difficult as for a vacation. What is a CI is dependent on context, time and perspective. Like a pair of shoes are irrelevant when being part of the luggage, yet important enough not to forget as item to take with you (unless you always walk barefoots). Everyone knows you need to have plans, schedules, requirements, designs, repositories and all the other stuff, and that you need approval to avoid getting in a fight and spoiling the good spirit within the team or with the stakeholders.
But if everybody knows that and if everybody has no trouble of organizing a vacation in a proper way and in good spirit, then why is it so difficult to make a list of those items for a development project? If we list all containers that can hold a bunch of items, and identify those containers (i.e. the suitcases), the content of a container (i.e. the luggage) and the items of the luggage (i.e. the shoes, socks, etc.) then we have all CIs that we need. Note that a container can contain another container (e.g. a suitcase can contain a bag). Of course, you don't have to go down until atomic level. When items are always held together (e.g. shoelace and shoe), then there is no need to identify them separately.

One final note:
Why aren't development projects like vacation to us?
Why aren't project teams like groups of friends going on vacation together?

Update 14/4/2007:
Added labels.