A CRL has value, and is acceptable, by virtue of being signed. Since the CRL is signed, how you obtained it is of no consequence whatsoever on its acceptability. That's the point of certificates and CRL: they can be distributed over arbitrary networks, protected or not, even plain HTTP, email, avian carriers... it does not matter.
Conversely, that the CRL is "online" does not make it any better; you still have to verify the signature, dates and so on.
Thus, CRL (or certificates, or OCSP responses) can perfectly be embedded, transmitted along with the data they qualify, or whatever. For instance, a CMS (PKCS#7)
SignedData object contains fields called
crls precisely to embed certificates and CRL (and OCSP responses) that receivers of such an object may find useful for validation purposes. In a similar vein, when a SSL/TLS server sends its certificate, it sends also some extra certificates (a "chain") that the client may use (at its leisure) to validate the server's certificate.
When a CA splits the CRL into multiple sub-CRL, the scope of each CRL is explicitly indicated: a certificate is in the scope of a CRL if the certificate contains a (critical)
CRL Distribution Points extension with a "Distribution Point" that matches the
Issuing Distribution Point extension in the CRL. See RFC 5280, section 6.3.3, step (b).(2).(i). This CRL splitting is thus not a problem.
An even more extreme splitting is incarnated by OCSP. OCSP is both a format for signed objects (the "OCSP responses"), and a communication protocol to obtain an OCSP response from an online responder. Each OCSP response is functionally equivalent to a CRL that talks about a single certificate. Thus, this is like the most split CRL that you can imagine, and yet it does not create any ambiguous information because each OCSP responses designates explicitly what certificate it is talking about.
Therefore, that a CRL is split or not does not induce any weakness; and obtaining fresh CRL from the CA would not fix anything either, since the downloading process is not protected anyway.
As for your second question: indeed, revocation status is, by definition, a transient property. On the one hand, that the signer's certificate was unrevoked at some point in the past (that's the information provided by an old CRL) does in no way guarantees that the certificate is still unrevoked, and, in particular, that the private key was not compromised in the mean time. On the other hand, recent CRL don't talk about expired certificates (and that's the point of certificate expiration: to prevent CRL from growing forever).
The exit out of this conundrum is time stamps. With a time stamp, you can somehow "freeze" an object at a moment in time. The idea is that, at date T, you take the signed object, along with all certificates and CRL that can be used to validate the signature at that date. You put all of these in some archive format, then obtain a time stamp on the whole. At a later date T', you validate the time stamp; if the time stamp is valid (at date T'), then you know that all the archive contents already existed at date T, and you can then proceed to validate the signature and use the certificates and CRL as if the current date was still T. The concept is that IF you had done the validation at date T, THEN you would still remember it, and act upon it; with the time stamp, you know that at date T all the certificates and CRL existed as is, and thus you could have done that validation.
There are a lot of subtleties in that process, which is why some standards have been defined to support it properly. Look up CAdES (and possibly its brothers XAdES and PAdES, for XML-DSig and signed PDF, respectively).