Pre-2011 VCAA exams and assessor reports are incredibly useful. Mark Kelly's website also lists what questions are relevant and not in his post-mortems too (I think for VCAA 2008 to 2010 from memory). You get a good idea of what's not on the study design anyway, and it does let you realise a bit more about what the current study design's focus is too. Spamming a lot of exams wouldn't really help you that much anyway. Once you know the course well, the big part is picking apart and refining your answers.
a programming language as a method for developing solutions that meet specific needs
The study design does define content for the sacs and for the exams, so it does include dead obvious things. You could interpret this dot point to be telling you that you need to use a programming language in ITSD and that you should learn how to use it so you can do stuff. As opposed to looking at programming languages from a purely theoretical perspective.
You can look at most study design dot points in parts, and ask "what is a programming language" and "what are specific needs". So the stuff you listed is really just fleshing out what a 'programming language' is.
The second bit states "developing solutions that meet specific needs", which is a pretty major concept in SD (you make stuff to do get something done basically). You could go study more about 'solutions' and 'specific needs' but it's kinda self-explanatory and not all that deep though. Specific needs of users comes up somewhere else in the course too, most likely in the dot point to do with designing user interfaces.
With how deep you should go, well it's not that well defined in the study design, and realistically this kind of dot point wouldn't really have a specific exam question written about it, since it's just a general concept. If they specifically wanted you to learn about programming language generations and then be able to answer exam questions about, then it'd be defined clearly - just like the 'processing features of programming languages' is clearly defined in the next dot point.
But you can't deny that it's worth knowing about what compiled/interpreted etc. means, since it does clarify a bit more about what programming languages actually are. The way I decided to approach it was mostly I just read into dot points until the content I'm reading about gets way too technical/obviously not Year 12 level stuff or until I lost interest in reading about that particular concept. If I didn't know what the course wanted from me, I just took that as a reason to go and read/think/discuss more.
I might as well link something from VCEIT, but I think this page does show one way of breaking apart these ambiguous dot points
http://www.vceit.com/p/format-structure-of-io.htm