Totally plausible. Depends on how you are stopping Apache.
If you are doing a nightly HUP to get the servers to start the new log then you should not have a problem. Any clumsy stop and restart and your own your own though!
However, any connections present during the nightly HUP will be lost and those punters will have to reconnect. Bit of a pity if they're in the middle of a big download!
If you're logging the bytes served as a part of the request, then the connection isn't logged until the download is complete, hence those connections that were dropped because of the HUP will be missing from the logs.
Have you looked at the new 2.2.12 release?
One of the changes is to make the "piped through rotatelogs" more robust so that you can defer the rotation out to the rotatelogs utility and let it top and tail your logs without the need to perform the nightly HUP. So no dropped connections and no missing log transactions if your logging bytes served.
The doc's say
The rotation occurs at the beginning of this interval. For example, if the rotation time is 3600, the log file will be rotated at the beginning of every hour; if the rotation time is 86400, the log file will be rotated every night at midnight.
If you look inside rotatelogs it's not obvious how they're doing this as there's no magic numbers at all until you spot the line:
tLogStart = (now / tRotation) * tRotation;
And this will align the start time with the start of the current hour (for tRotation == 3600) or the previous midnight (for tRotation == 86400). Who knows what it'll do for any other numbers, e.g. 16432?
Edit: I forgot to say that we've seen problems with graceful not behaving very gracefully. Specifically, just leaving child processes hanging. This seems to have been acknowledged as v2.2.12 now has a new config directive GracefulShutdownTimeout which specifies a timeout after which the httpd process terminates irrespective of any requests being served.