Oooh, that's a tricky one.
nextUpdate field is meant to be a (future) date at which a new, updated version of the CRL should be made available. The idea is that if you have a cached CRL, then there is no point trying to download a new one before that date.
In "true X.509" each relying party (a "relying party" is "some system which tries to validate a certificate") is supposed to have its own policy with regards to how old a CRL can become before becoming "too old". Yet a RP cannot guess when a new CRL will be available for all possible CA; we use certificates precisely because a RP does not know all possible CA in advance. Hence the
nextUpdate field which conveys information about the CA update policy.
In practice, though, everybody took
nextUpdate as a CRL expiry date. So the
nextUpdate field means "don't bother download a new CRL before date T", all implementations of X.509 certificate validation consider it to mean "don't use this CRL beyond date T". That's not the same concept. "True X.509" does not handle CRL expiration at all, since every RP is supposed to apply its own policy, but that does not work in the Real World: existing CA, both root and non-root, don't have coherent enough CRL update policies to make a RP-local policy workable. E.g. some CA will update CRL only once per week, or even less than that, especially for offline CA; while others publish new CRL every hour.
Since everybody uses
nextUpdate as a CRL expiration date, the CA have adapted and also fill that field with these semantics. Microsoft has also defined an extension called "Next CRL Publish" (188.8.131.52.4.1.311.21.4) to convey the information about the scheduled next CRL publication date, i.e. the historical role of
nextUpdate (this is a Microsoft-specific extension, I doubt anybody else uses it).
A common strategy for CA is to use some overlap: for instance, they publish one CRL every 24 hours, and the
nextUpdate field is set to
thisUpdate + 36 hours. That way, the new CRL is available 12 hours before the previous one "expires". Most clients will bother downloading a new CRL only if the one they have in their cache has its
nextUpdate "in the past". Some clients (notably Windows) will download the new CRL some time before the
nextUpdate if they have some good indication that a new CRL is indeed available, thus making the pre-fetch worth the effort (e.g. because there is a "Next CRL Publish" extension).