I'll give you examples. I'll talk about the problems in those examples. But I won't classify them beyond the close reason itself: doing so leads to something akin to a hash collision - multiple distinct problems getting lumped into common category, with unhelpful results. Worse, it implies that you can skip identifying a problem entirely, and apply close reasons based purely on a superficial examination of a question - while this is often feasible, doing so in every case leads to cases where useful questions are closed based on irrelevant factors rather than the presence of actual problems on the site.
This is fairly obvious: a question asks for a solution to the same problem as a different question.
A is a duplicate of B
unclear what you're asking
Exactly what it says on the tin: it is not clear from the question what information the asker needs in order to solve his problem.
Note that many "unclear" questions are still questions - and they may even be answerable, if the answerer is willing to make sufficient assumptions regarding the problem. Answerers who are gamblers or psychics have a distinct advantage when it comes to answering these questions - and if such a question attracts a skilled answer from such a lucky / clairvoyant answerer, it may well be worth editing it to reflect the answer rather than closing it. The vast majority of these questions do not attract such answers, however.
This question is unclear. In fact, it's not even clear that it's a programming question. It might be off-topic, it might be impossibly broad, or it might be trivial - who knows?
This question is also unclear - it mentions errors without including them, and hints at the presence of other problems without describing them. In fact, it has a very helpful answer that spends a great deal of time politely pointing out how utterly out of his depth the answerer is. This question is unlikely to be clarified because the asker has no idea what he's actually doing, but if he did it would likely be too broad as well.
Answers on Stack Overflow are limited to a paltry 30,000 characters. That's barely enough for a brief academic paper; a comprehensive tutorial on a subject of any size is unlikely to fit, and even a svelte book on any programming topic is right out.
In practice, very few answerers have the patience to write even that much. This is fine; there are other sites that cater to full-length articles. We're here to answer specific questions.
But some questions aren't specific. Some questions just lead to more questions. Others explicitly contain multiple, independent questions! A common motivation is an asker with a fairly basic understanding of a topic who wishes to leapfrog past the whole "study, trial and error" page and find that mythical Royal Road to programming. These are discouraged - rather someone ask multiple questions (or read the answers to existing ones), building their knowledge from the foundations up than require a personal tutor to walk them through the process.
You know what they say about opinions... There are a bunch of questions that are either designed or destined to collect raw opinions, devoid of anything verifiable. Sometimes, these are a lot of fun; other times, they're fertile ground for flame-wars.
These are supposed to be self-explanatory - hence the recent removal of a couple of oft-misinterpreted ones; if it's helpful, I can provide examples for them too though. The newest off-topic reason is:
This question was caused by a problem that can't be reproduced or a simple typographical error. While similar questions may be on-topic here, this one was solved in a manner unlikely to help future readers. This can often be avoided by identifying and closely inspecting the shortest program necessary to reproduce the problem before posting.
...and it's aimed squarely at this sort of thing.