Currently, there are two options presented when one starts watching a channel. Live or Recording.
Would it be possible to have three choices:
Live
Recording from start
Recording At Live
Personally, I would always want "Live" if recording to be watching the recording Live as it makes it easy to rewind if one wants to whereas current live can only rewind the buffer and no earlier than when one started watching.
I think I understand, where you wish the "Live" option used the current time to enter the recording, as opposed to using the local client and its buffer which only starts from when you tune in.
I agree that this is the preferred experience, but do note that it does present an odd situation of what to do when the guide time for the airing ends, but you wish to keep watching the same channel (for say, a recap).
Most DVRs hard subscribe to the server/client model, where every "screen" is merely looking at what is on the DVR. Channels is different, in that most all viewing is local (client-based), so it makes things like this awkward. I know (and believe the developers do, too) that this makes casual edge cases such as yours hard to deal with ... but at the moment what you want is not easily workable because reality—and other people—make your ask 4x as hard as it should be.
(Also, I don't think this is the first time this has been requested.)
The current model, when selecting recording, essentially ignores when the guide time ends as you are watching a recording, not the "live" broadcast. What I am asking for is to have the recording view start at "live" or perhaps a few seconds after live. Perfectly fine when reaching the end of the recording to have to select what I want to watch next. This gets around the limited buffer issue on pause and or rewind as one is reading the recording, not trying to process the live stream and finding a place to store it.
I've been a Channels user for about a month now, and also wondered why you can't jump to the live point in a recording (and I do mean recordings, not live TV). I like to use a DVR for time-shifting sports events. When watching an event, I'll either jump to the live point and join a broadcast in progress, or start at the beginning and fast-forward through the commercials/time outs/intermissions/half-time, etc. It's not a show stopper, because it's pretty easy to button-mash my way to the end. But, I've always wondered why there isn't an option to start a recording at the live point. It would seem pretty straight forward. 
I totally agree with jonsrosshunt. Having used 4-6 tuner TiVo devices for a long time, I developed a habit of watching multiple "channels" (especially live sports) at the same time and switching back and forth with the benefit of a having the automatic "recording" (aka the buffer) that TiVo always kept per tuner. I realize that Channels uses a client-side buffer instead of a server/DVR approach for live TV, but adding more features to watch active/live recordings and treating them like live channels to switch between them easily using PREV (double pause/play) or the quick guide (down arrow) would be HUGE for me. Now that I am thinking about it, treating all recording playback (live or pre-recorded) as a live channel might be useful for switching between content. FYI - I am only a week or so into my Channels trial and have been very impressed. In fact, this may be the only missing feature from the TiVo that I am really struggling with.
ANOTHER IDEA: A stepping stone to what I described above might be an optional feature to maintain a current AND previous channel client-side buffer so that switching between 2 live sporting events using double pause/play would maintain and preserve the cached buffers. That way, without creating a DVR recording, there would be a way to bounce between events with the ability to pause event #1, switch to the other event #2, rewind to see a missed play, switch again to event #1 to resume or fast forward, etc .... Clearly, the client app would need to have a background process/thread running to keep the "previous" buffer up to date. Doing something like this might no be feasible given the design, but I know that I would use it all of the time.