(1) The book is not finished yet. But it will appear with MIT Press, and I expect it to appear over the next year and a half or so.
(2) Realm is best read after HtDP [1e or 2e] or some other course on plain programming (not necessarily program design). It teaches (simple) programming in Racket.
(3) HtDP [2e] does NOT teach programming in Racket. It uses several teaching languages, each matching a stage in the convex hull of the design recipes (tactics) of a certain part of the book. HtDP's design tactics do away with the usual "everything is a Turing machine so learn by coping me" approach.
I wish more people were as excited by Racket as I am.
The "comments" are really an introduction to type systems, along with general good practice.
The ability to describe a function by purely it's signature without the presence of mutation makes reasoning through hard problems more straightforward.
The book is used best in conjuction with Coursera's https://www.coursera.org/course/programdesign
Realm of Racket is designed more or less as a self paced tutorial. It is in the tradition of Land of Lisp. It is targeted at a broader and more general audience.
How to Design Programs starts at the very beginning and has a lot more principled of an approach, focusing on FP and programming as calculation of values. It's by far my favourite introductory programming text.
That contrasts directly with my opinion after 20-years of development experience working on applications across a number of industries and in teams of 1 to 100. Not 'all' programmers can be or are good, and definitely this is not true for 'all people' in general.
After such a start, why then should I read further? I'm genuinely interested to know the answer.
Well, except that seems to be covered better by the preface to the firat edition.
Your idea that some people "have it" and some don't is just not true with almost anything in reality. Prodigies are extremely rare, and everyone else who "has it" got there by practicing in their field. Anybody (assuming no other learning disabilities) can become a programmer, and a good one at that, if they honestly believe they can do it, study the foundational skills they need for it, then practice and practice.
Try to remember how you became a programmer - chances are you started learning at an early age - you already had the foundational skills in language, math and science etc, because you were competent in school, and you probably spent a large part of your youth engaged in programming. You're no prodigy, and you didn't have it to begin with. Instead of saying "I can't do it", your probably the type to ask "how can I do it?".
The "bad", or non-programmers are more likely to be the ones who say "I can't do it", "it's too complicated for me", etc. You can crush the chance of these people ever being competent by simply agreeing with them that they can't - because if they don't have the belief that they can, they won't bother spending hours learning the foundational skills they need, or the thousands of hours practicing which would turn them into good programmers.
From my teaching experience, the learner's belief is by far the most important factor in their learning. Those who have no belief will simply not put any effort into learning, and will never progress. The author obviously understands this too, and invites the reader to first believe they can do it, so that they continue reading.
Try to write some educational material for programming, and introduce it by saying "You probably won't ever get good at this, you suck, why are you still reading?", and see how many engaged readers you get.
The preface to the first edition expressly made this clear, introducing the book as "the first book on programming as the core subject of a liberal arts education", and proceeding to lay out the case for programming as a liberal arts core subject . It specifically notes that "traditional forms of programming are useful for just a few people." (emphasis in original)
 For that explanation, see "Why Everyone Should Learn to Program", at http://htdp.org/2003-09-26/Book/curriculum-Z-H-2.html
The book is saying that everyone can be good (although like guitar, through practice). That's very different from "everybody will be good" or "everybody will enjoy it" or "programming is for everyone"
Sometimes it's hard to know if its for you or not until you've immersed yourself in it for long enough. Unfortunately for the woman you mentioned, this was likely many years of her time. Other people know immediately. Either way it doesn't mean that they couldn't learn or get nothing out of it.
You don't have to be a chef for knowing how to cook nice things to be a useful skill to have.
If good programming requires practice, and some people cannot stand the practice, then they cannot be good programmers.
"Good programming ... everyone who likes programming or can stand to do the significant practice can do it."
"Crap programming ... everyone can do it."
The statement at the start of the book is just saying that anyone can be good, but it doesn't say everyone will.
That depends on the degree to which you like or dislike that thing. If you don't like something to the point that you can't stand to pursue the practice that would make you good, then you are not able to become good at it. If you aren't able to practice, then you aren't able to be good. Not everyone will, agreed, but nor can those who can't stand the necessary practice.
"Anybody (assuming no other learning disabilities) can become a programmer, and a good one at that.."
I still haven't seen any actual evidence to support this statement, and have seen plenty that does not support it across my career and interaction with many programmers. It should be obvious, I would think, that with all jobs there are some people who are good and some who are not. Why is programming so special that everyone can be 'good'? It's not.
"Those who have no belief will simply not put any effort into learning, and will never progress."
This might sound harsh, but this is fine by me. I like the idea that programmers / doctors / musicians / etc have been and are highly-motivated and dedicated, and weren't molly-coddled throughout their career. If they need to be babied into doing something, they can do something else.
Usually, if someone struggles progressing, it's because they're lacking some foundational knowledge to understand it. I see this most often with math, people put off by type theory and such because "ooh, scary notation", which needs learning before you can even begin to read the literature. Even basic math is a no-starter for some people, because they were unable to grasp the way arithmetic was taught to them in infant school, they just think "I'm terrible at math" for the remainder of their life - rather than what they should think - that they weren't taught properly to begin with. It's actually quite fun to teach the basics to adults who always thought they were crap at something, because you see them transform into hating a subject into loving it. Perhaps the "bad" programmers you speak of have simply lacked someone to mentor them and bring out the best in them?
I think you're holding the bar too high for "good" too. What do we even mean by a good programmer - one who writes few bugs, solves problems the quickest, writes independent, cohesive modules, or a combination of many factors? - surely then we'd have a mix of people who are good at some of these and bad at others - then there's nobody who's going to be "good" at all of them. If writing few bugs makes a good programmer, then such programmers are extremely rare. Good means competent enough to solve problems with code - it doesn't mean everyone is "exceptional".
I don't believe that I could become an exceptional author for example, but that doesn't stop me from writing. Imagine we only taught writing to children who show the aptitude to become authors? Of course, this can't happen - the opportunity needs to first be there for one to consider dedicating themselves to it, and you don't motivate someone into trying by telling them they can't do it. Writing has practical use besides being an author - it can act as "external storage" for our brains, and it's a communication tool - as is math, and programming has the potential to be far more useful than both of these, if people didn't see it only as a career path.
As for being "moddy-coddled", you'll probably find that most talented individuals have had good mentors at some point in their lives - who can point them to the most suitable material to learn from. Autodidactism only gets you so far, because you don't really know what it is you're learning until you've learned it - if you're trying to specialize in something, it's not very efficient.
> This might sound harsh, but this is fine by me.
I don't think that's harsh, but I think everyone should have the opportunity to learn before brushing them off as incompetent. From personal experience, I have little time for people who don't want to put in the effort to learn and progress, but I'll give hours of my time away for free to those who genuinely put in the effort. It's not the case that some have the ability to begin with - it's that I need to find the right way to explain something in a way they understand.
Because the stated assumptions aren't always reflective of the actual design principles of a product. HTDP is a solid course that in practice does not compromise on quality for the sake of popularity.
That everyone could (and should) learn to program is also a popular thing to say these days. This generally means that you can discount the importance of any one person saying it to that person's beliefs.
The statement at issue very much is central to the actual design principles of HtDP.
... and Lisp :(