Thanks @mathieubossaert and @yanokwa for all that helpful feedback. I like how @seadowg is planning to incorporate it.
Thanks also to the @TAB for a good discussion yesterday. I know I sounded tired in response to your feedback. It's because I'm tired. 
The feedback was good. We may not act on all of it immediately but I think the most helpful thing was to get confirmation that there's broad agreement this is a good area to improve. I'll do my best to address here what I remember was brought up. @Tino_Kreutzer in particular expressed eagerness at discussing further based on extensive training experience in the field. @Tino_Kreutzer do you want to set up 30 mins with me and possibly @seadowg?
Broad desire for animation
We played around with a number of animation concepts including @Florian_May's progress bar concept above and something like the accuracy circle shown on a map which @danbjoseph mentioned. We liked the ones that have a spatial representation but we think they only have meaning to someone with a mental model of maps and accuracy. Progress bar representations do seem like they'd lead to a more generic sense of "maximize the score". I believe that if you saw the dialog dynamically changing colors you'd feel that those do too.
We decided not to include animation for now because we didn't feel confident that they'd add value beyond colors. We also feel like the actual accuracy number would be important to display because some people do understand accuracy and may want to make a different decision at 10.5m vs. 9.5m for example (and likely also based on time elapsed). We have designed some analytics to try to validate that and further iterate as needed.
One idea a few folks mentioned and that I'm warming to is to add a new parameter to define the "unacceptable" cutoff. We picked 100m because it's about a city block and there are few contexts where this would be sufficient. But @chrissyhroberts points out that there are cases where maybe you're under heavy canopy and all you care about is the broad region you're in. Additionally, there are cases where you really want a high-accuracy point and maybe even 10m is unacceptable. Making the "unacceptable" cutoff configurable would give a lot more power to form designers. They could do things like define the automatic capture cutoff and the unacceptable cutoff the same to signal to data collectors that they should wait until auto capture.
Related to that, I'd like to make an additional suggestion to support an automatic capture cutoff of -1. This would mean that the point is never auto captured.
You wanted a point. Now you see a dialog with a ton of numbers and have no idea what any of it means.
This was particularly emphasized by @tomsmyth and it's something we've wrestled with. Our biggest group of Collect users is of the lightly trained type. But we also know we have very sophisticated users who benefit from the rich information provided when capturing a point. We tried to balance that by making the accuracy number really large and by putting the troubleshooting information smaller and on a white background. I'm hoping the font size changes @yanokwa described will further help. I'm open to ideas for de-emphasizing the troubleshooting information but I think we'd lose value by removing it.