Very interesting problem. There are many questions here so I'll give my shot at one. There is such a thing as real-time differential GPS. When we did NASA flight tests, we sent an engineer up to our landing site to setup up the GPS station ahead of the airplane. The station was placed at a known accurate location and broadcast corrections to a GPS receiver on the airplane correcting our position data during the flight. As the airplane approached the airfield (where the station was located), we could begin obtaining DGPS on the first approach. So, we could get good enough accuracy to auto-land an airplane.
If you really need meter/sub-meter accuracy, then DGPS is going to be (at least part) of your solution.
First of all, the GPS Almanac consists of information about the GPS constellation, satellites' health and their course in order to make it easier (possible) for your receiver to find them in the air.
(Most of the time, you do not need to download that since you did before, but that is a discussion for another Q/A). The point is, almanac is not important for receiver positioning update rate. The receiver has to have it and then it can work.
(GPS.About.com,
GPSWorld)
The GPS receiver calculates its position from distances to satellites, this technique is called Trilateration. But the important is, how it measures the distances (!). It measures the distances to satellites by comparing the code it receives from satellites with a replica of the same code it creates. Each GPS satellite transmits signal which a specific pattern. The receiver knows the patterns, so it tests the received code to its own replicas to know from which satellite the signal came from.
Each satellite transmits a pattern of 0 and 1 (for example: 00111010111010101001...).
The civil signals has code of 1.023 Mcps (mega-chips per second, chip = bit without information, every micro-second one chip). The receiver creates its own replicated pattern which goes the same.
We now assume ideal situation when your clock is synchronized with the satellite clock. In such case the satellite transmitted the first '0' in time t0 and your code inside the receiver also generated the first '0' at t0.
The code from the satellite will arrive with a delay, td. So, you will receive the first '0' from the satellite at td. The receiver finds out the delay by shifting its replica until the replica and the received signal'start at the same time' (this is very rough explanation, the correct therm is that the receiver correlates the received signal and replica and the time delay is found when the correlation function reaches its maximum).
I hope this picture from Kaplan:Understanding GPS will help to demonstrate the principle, the last picture is simplified correlation function,(Tc is duration of one chip (in our case 1 micro-sec):
So, regarding the position update. To estimate a position from code delay every second once the satellite code is tracked is not a problem. The receiver has only to make some shifts to estimate the delay of signal it continuously receives and replicates. These days, we were testing some of our application with the 10Hz (10 updates per sec) and 20Hz (20 updates per sec) receivers.
Best Answer
To answer your question strictly as asked, this behavior is due to the fact that most consumer GPS receivers and the NMEA protocol evolved from navigation applications.
In navigation hardware there is almost always an accuracy threshold that must be satisfied before a position is reported. This is to prevent users of the position, both human and computer, from acting on inaccurate data with possibly disastrous result.
Some GPS receivers allow you to set the accuracy criteria, others let you "see" inaccurate positions with the accuracy reported at the same moment. But in general there will be a pre-established threshold beyond which they will not report a fix.
There is nothing in the physics or mathematics to prevent reporting such positions as long as there are 4 satellites in the fix. It's purely user interface policy that prevents it.