I think it would be most easy to treat the components independently whenever possible. The components involved in your course example would map to navigational language (#10 in the wimpy point) and multi-language content (#12) (deliberately leaving out #11 to hide my confusion about that one).
While it might be somehow cool to be able to control the language used in the navigation depending on the language of the currently displayed content item, I don't see any realistic use case that would make that worth banging our heads against the wall to come up with a way to implement it.
Also I would suggest, for the sake of simplicity, to make the user's language selection site wide. E.g. if I choose german as my preferred language, it will be my preferred language on all subsites of the system, until I change it to something else. If I don't choose any language than it will be based on my browser's settings, and it's most likely that I'll visit different parts of the site with the same browser anyway. This way user preferences can be stored in the user record (or a specific cookie) and don't have to keep track of subsites.
Packages that are handling multi-language content might decide to serve specific content items in a different language than the one preferred by the user, most likely because it's not available in the preferred language. E.g. like in your example with the user's language set to Swedish and most courses available in German only.
The only problems that I can see with this approach are possible character set clashes - for example when you want to view the course in Thai and have your navigational language set to Swedish. OTOH I doubt that this is a big issue in practice, and don't see an easy way to avoid it. (Also propably users who deal with different languages are more likely to have Unicode-enabled browsers installed).
Speaking of multiple languages for the same user, I think it would be benefitial to have an ordered list of language preferences instead of a single preferred language - the way that browser settings already implement them. This belongs to #3, language selection. Maybe this could include a proc that takes a list of possible (available) languages, and returns the one that is most applicable for the current request.
So a multi-language content package could tell the language selection mechanism: "hey, I got my item in these three languages: en, sv, de", and the mechanism would reply with: "the current user wants to see it in sv". The component handling the navigational language (gp-lang) could use this mechanism as well. This way all the knowledge about the current cookie setting, browser preferences, default language etc. could be in one central place.
