I think there's been a lot of misinterpretation of the original post here, or I'm misinterpreting the responses. If I may rephrase it, it's asking if the implementation might change so that, even though the sequence of UInt64 values returned from the PRNG is the same, the sequence of UInt8 (and similar) generated from this UInt64 sequence is different.
The concern implied in the post is that there might be some sort of buffering added, so that the unused bits could be returned in future calls (e.g. generating one UInt64 value then returning it byte-by-byte for the next 8 calls for a random UInt8). But an even simpler concern would be that the way truncation is done might change, e.g. from returning the least significant byte to returning the most significant byte. Without a documented guarantee in this area, you can't rely on reproducing anything other than the UInt64 sequence for a given seed, making this API very tricky to use correctly with PRNGs, as @Jens notes.