You might like to re-consider your Solution check mark. When I was system testing, the person who raised the bug had sign off. Just sayin' 
Thanks! While I happen to have a copy of The Coding Book in question I didn't write it, and I'm not deeply familiar with all the exercises in it. Looking at the page you posted it appears to me that the "Zorg" sprite that you're going to clone should already be at y:-200 x:-140 from a previous step. Therefore that's going to be where all the clones will start from anyway even without explicitly moving them there after showing them.
Looking at the page you posted it appears to me that the "Zorg" sprite that you're going to clone should [have been coded to] already be at y:-200 x:-140 from a previous step.
If I understand you correctly, as per my bracketed insert, then agreed. That's how I got it to work.
Could I ask you to let the book authors know, please? I used the form on their web site to advise them but haven't had a reply as yet.
hmm... didn't we just establish that if you follow the book step by step the issue will not arise at all?
I did follow the book step by step. That's where the problem lies.
That's exactly what the book tells you to do. I thought my photographed page made that clear.
Edit:
Re: "from a previous step". There is no previous step. Are you referring to the block I've ringed here on that same page.
If so, I can see that before a SHOW is written into the block, the sprite would still be hidden. But we're not retaining that block as written in the final code.
That single block is then MODIFIED, at the foot of the step, to include the SHOW before move. It's writing the SHOW before the move that we're agreed is the cause of the problem.
Edit #2:
You're still not out of the woods yet @jens 
I agree your statement about moving Zorg to -200, -140. That's under REVISION 1: *** CHANGE ZORG'S STARTING POSITION AND SPEED SO THAT AGENT X HAS A FIGHTING CHANCE. *** on p16 and Tested on p17.
This is how we get to Zorg's final version of his movement block at the foot of panel 4 on p23...
Page 9 panel 6, copy this code for Agent X:
when flag clicked
set size to 50%
go to x:0 y:0
Page 14 panel 2:
Duplicate the Agent X sprite and rename it to Zorg
Page 16 REVISION 1: *** CHANGE ZORG'S STARTING POSITION AND SPEED SO THAT AGENT X HAS A FIGHTING CHANCE. ***, panel 1:
Click on Zorg's script space.
Find the 'go to x y block' connected to the 'starter block'. Change the fields [my edit: from 0,0] to match:
go to x: -200 y: -140
then test it on p17. That's the 'previous step' that you refer to. So far so good.
This block does not change again until we get to Page 23 panel 4 (see previous screenshots) where we:
Uncouple from the existing 'when flag clicked' header
Couple to a new 'when I start as a clone' header
"Your script should look like this:"
when I start as a clone
go to x: -200 y: -140
set size to 50%
(change to the costume script - which doesn't concern us)
then
Insert 'show' into your setup script:
when I start as a clone
show
go to x: -200 y: -140
set size to 50%
By my reckoning the block that, in isolation, looks to be the 'previous step' now no longer exists because it has been used up in constructing that final version of Zorg's 'when I start as a clone' block.
Shared here:
https://snap.berkeley.edu/snap/snap.html#present:Username=geronimo&ProjectName=Octododge10error
I'd be grateful if you could review it for me. If I've not follwed the book exactly, I'll be the first to hold my hands up.
Geez, I did not write that book and I'm not gonna defend it, especially since there seem to be ambiguities in there (as in most books) that others have also run into. But on p.17 it clearly tells you to make sure Zorg is placed at exactly x-200 y:-140, doesn't it? If it's already in that very position things work even if you show a clone before moving it elsewhere, because the "elsewhere" is also going to be that very position. I agree that it would be a good idea for the book to tell you to again make sure that "Zorg" is placed where they expect it to be, but - and that's my point here - this doesn't seem to be a bug in Snap. Phew!
Noodge? Really? And in what professional environment does a developer unilaterally close a reported bug? Maybe in education but certainly not in business.
Please forgive my poor attempt at lightening the mood with my little 'not out of the woods' quip - I'm English and we tend towards friendly banter and thicker skins. But If you've read that friendly little elbow nudge then you'll also have ready my analysis of why I think, IMHO, that Jens hasn't yet made his case for claiming that there's no Snap! bug here.
I'm grateful for what is apparently far too much time and patience that three Snap! developers have granted me, but I thought that was what these forums were for. On the other hand, I have been very patient in having to repeat myself to make my point, which also bumped up the message count. In the financial and order processing environments I've worked in, getting to the underlying truth of the unexpected result is what's important and message counts don't come into it.
As I mentioned above, I've already written a very polite email to the publishers on their Contact Us email but having invested this much time and effort, an additional hard copy version won't take up much more time.
I don't imagine you're trying to be condescending, but I don't appreciate being put on some arbitrary naughty step for taking the time and effort to chase down what I still consider to be unexplained behaviour.
I thought we were all agreed that, if there's a bug in anything, it's that book. Is that not the case?
To be honest, I'm not sure. Jens' argument relied on this logic:
"But on p.17 it clearly tells you to make sure Zorg is placed at exactly x-200 y:-140, doesn't it? If it's already in that very position things work even if you show a clone before moving it elsewhere, because the "elsewhere" is also going to be that very position."
But I've demonstrated that that code block no longer exists because it was dismantled and partly used in a new block. So at that point, we didn't have a definitive answer.
It may be that the p.17 thing is a red herring that has confused the issue. You can see why I was trying to discount it.
If so, that leaves us with the position and effect of SHOW in this block:
when I start as a clone
show
go to x: -200 y: -140
set size to 50%
If SHOW in that position has the effect of spawning the sprite at 0,0 and also leaves it visible for a collision detection before 'go to x: -200 y: -140' can be executed, then that would account for what I see when I step it through.
If that is the case and also known and accepted snap! behaviour, then I can write to the publishers and let them know that the code as presented in the book will end the game instantly.
Agreed?
Yes, we certainly can agree on that.
As to whether you or Jens is right about the book, I don't have the book and don't want to hazard an opinion based only on the page you posted. But, yeah, that's between you and the publisher.
By the way, I should not have called you names in public. I plead unfamiliarity with social media; I'd forgotten that I could send you a message privately. I apologize and have deleted the post.
But you'd still have called me names privately?
Don't worry about it - I didn't get this old and this ugly without a little sabre-rattling along the way. A little repartee is good for the soul 
Thanks for your help in sorting this out, I'll certainly follow it up with the publisher.
What. Is. The. Bug?
No bug in Snap!
The problem is in the book (as per earlier discussions before we got side-tracked on the p17 movement block which disappeared because the code was used to create the later 'when I start as a clone' block on p.23).
When I contact the publishers, I'll let them know the following:
The block:
when I start as a clone
show
go to x: -200 y: -140
set size to 50
stops the game immediately because of the condition you described in one of our earlier chats, namely:
"Clones are created at the exact position of their parent. If you would like the clone to first appear at a different location that's fine if the parent is hidden , because then the clone will be hidden, too. Hidden sprites can themselves sense collision with other clones but cannot be sensed to collide by other sprites.
BUT once you SHOW the clone, which in your example code happens BEFORE you move it elsewhere, it can and will collide with whatever is at the original (i.e. the parent's) position".
As agreed with @bh, to allow the game to continue as intended, the 'show' command needs to come after the 'go to x: -200 y: -140' command in the block.