I see this question is 12 (!!!) years old, but I’ll add an answer anyway. I ran into the same confusion while reading Evans and Vernon and thought this might help others.
Like you, I was puzzled by:
1️⃣ Subdomains vs. Bounded Contexts
Subdomains are business-oriented concepts, bounded contexts are software-oriented. A subdomain represents an area of the business, for example, Sales in an e-commerce company (the classic example). Within that subdomain, you might have several bounded contexts: Product Catalog, Order Management, Pricing, etc. Each bounded context has its own model and ubiquitous language, consistent only within that context. As a matter of fact, model and ubiquitous language are the concepts that, at the implementation level, define the boundary of a context (terms mean something different and/or are implemented in different ways depending on context)
2️⃣ How they relate
In short: you can have multiple bounded contexts within one subdomain. To use a different analogy than the existing ones: subdomains are like thematic areas in an amusement park, while bounded contexts are the attractions within each area, each with its own design and mechanisms, but all expressing the same general theme.
3️⃣ In practice
In implementation, you mostly work within bounded contexts, since that’s where your code and model live. For example, in Python you might structure your project with one package per bounded context, each encapsulating its domain logic and data model.
Another reason to keep the two concepts separated is that you may have a business rule spanning across different bounded contexts and be implemented differently in each of those. For example (again sale, I hate this domain, but here we are): "A customer cannot receive more than a 20% discount" is a rule of the "Sale" sub-domain that, language-wise and model-wise, will be implemented differently in different bounded contexts (pricing, order management, etc).
Also...
When planning development, discussions start at the subdomain level, aligning business capabilities and assigning teams. Those teams then define the bounded contexts and their corresponding ubiquitous languages.
The distinction between the two matters most at this strategic design stage, it helps large projects stay organised and prevents overlapping models and terminology from creating chaos.
If you mainly work on smaller or personal projects by your own (as I do), all this taxonomy may not seem that important at first, but (I guess) the advantage is clear for people that witnesses project collapsing because of bad planning.
TLDR: