CORRECTION! CORRECTION! CORRECTION!
Upon further tests of this approach, I found that it was not reliably stalling the AppleScript -- and I determined why as well. This applies to all approaches discussed, whether Camelot's or mine.
The problem was that, after the "do script" is called, 'set frontWindow to window 1' (Camelot) or 'set W_ to windows of application "Terminal"' (me) may not identify the proper window as window 1 -- time is needed for that window to establish itself. On my computer, with my test script, the threshold is ~0.3 second; using 1 second would be sensible to gain a safety margin. I don't know whether a slow computer might increase the delay needed beyond this.
Given that, the simple solution is to add a 1-second delay at the appropriate point in the script.
For Camelot's approach, the script would become:
tell application "Terminal"
do script "blah"
delay 1
set frontWindow to window 1
repeat until busy of frontWindow is false
--sleep 1 (sorry, I find the script won't compile with this!)
end repeat
end tell
For my approach, the script would become:
tell application "Terminal"
do script "blah"
delay 1
set W_ to windows of application "Terminal"
repeat until busy of (item 1 of W_) is false
end repeat
end tell
I suppose this slightly increases the chance that someone will slip in a different "window 1." The only solution I can see for that would be to reference the window by its name; but that, too, might be compromised if a different "window 1" has the same name.
How do you test whether the delay introduced is sufficient? Do this: in a new Script Editor window enter
tell application "Terminal"
do script "blah" -- use a command that will take at least a few seconds to execute
delay 1
set W_ to windows of application "Terminal"
repeat until busy of (item 1 of W_) is false
end repeat
end tell
beep 5
If, upon executing the AppleScript, you get 5 beeps
immediately, then the delay is inadequate. The 5 beeps should not occur until Terminal finishes its chore.