OK, I went through some old trouble reports.
 
In '07 I reported that ASIO loop recording problem back in Sonar 7, gaps at the end of each loop, not using punch-in. That's what was fixed in X1d.
 
In '09 I reported a punch-in/out (no loop) problem in Sonar 8. The punch-in/out placed a clip seemingly recorded late by the amount of ASIO reported input latency and left a gap at the end, equal to the difference between the ASIO driver-reported RT latency and the Centrance reported latency. I don't know whether the driver report was to be trusted at that time, so other users may have had a gap or not.

An experiment on X3c:
Did a punch-in/out record of two measures taken during a 4 measure record, no looping. The recorded clip was placed properly in the timeline, data lined up in sync.
Imported the file into which the punch-in was actually recorded into a separate track.
Lined it up sample-for-sample with the clip placed by the punch-in.
The recorded file has an extra 256 samples at the beginning and an extra 84 samples at the end.
 
Then when I did a 4-measure loop recording with a 2-measure punch-in/out, each successive take was placed 256 samples later than the previous. My ASIO buffer size is currently 128. Reported latency is 148 in, 236 out.
 
I was about to go on with experiments, but suddenly the loop & punch-in record started behaving weirdly: each take in the loop was made of a tiny 1024-sample clip followed by a clip that filled the rest of the punch area. I saved and restarted, and the problem persisted. I give up.

bvideo
An experiment on X3c:
Did a punch-in/out record of two measures taken during a 4 measure record, no looping. The recorded clip was placed properly in the timeline, data lined up in sync.
Imported the file into which the punch-in was actually recorded into a separate track.
Lined it up sample-for-sample with the clip placed by the punch-in.
The recorded file has an extra 256 samples at the beginning and an extra 84 samples at the end.

I tried this experiment, but I'm not sure if I understand you correctly.
 
I have a four-measure clip and punch in over measures 2 and 3.
Now I take the punched section and copy that into a different track.
Then I line up the copy in the different track with the section that was punched in the original track.
But I don't see any difference, both clips start and end exactly at the start of measure 2 and end at the start of measure 4.
 
Could it be something as simple as "Snap to Audio Zero Crossings" being checked, so when you selected what you thought was two measures (and it looked that way visually unless you were zoomed waaaaay in), the selection itself had extra samples at the beginning and end due to it snapping to the nearest zero-crossing?
 
I've been tripped up many times when trying to cut sample-accurate loops because I had "Snap to Audio Zero Crossings" checked. Don't know if that's the same issue for you, though.

bvideo
I was about to go on with experiments, but suddenly the loop & punch-in record started behaving weirdly: each take in the loop was made of a tiny 1024-sample clip followed by a clip that filled the rest of the punch area. I saved and restarted, and the problem persisted. I give up.

That sounds like what happens when you comp record and stop the transport just after the the next iteration of the loop starts; all previous takes get split at the end of the snippet in the last take lane. All you have to do is delete that last partial take, and swipe through the last complete take with the comp tool to heal the splits in all the remaining takes.

Anderton
Now I take the punched section and copy that into a different track.

 
Hey Craig,  what Bill was saying is to import the audio file representing the punched take into another track. That audio file is longer than the just the punched section. That's not too surprising, but it seems there might be a correspondence between the extra length of that file, and the cumulative latency that occurs when loop recording with a punch in region.
 
I'll have to check that on the test I did.

Hi Craig and Brundlefly,
  Thanks to Brundlefly for the explanation to Craig; that's what I meant. The old loop recording bug and this punch-in/out problem have some evidence behind the scenes, and also a potential built-in workaround, which is the actual file where the audio was recorded. The clips placed on the timeline by the loop or punch record are really just different segments of that file, with the clip start and end edges locked so they can not be slip edited to reveal any other data in the file. Importing the file allows us to align, slice up, and set the clip boundaries correctly, if the data is all there. That was what I wanted to check next with multiple passes over a loop with an interior punch region.
  About the tiny clip, I get what you're saying. I did have recording set to comp, but every time that happened I had stopped the record after the punch-out point and before the end of the loop. In other words, I never stopped recording within the punch region. I think that means all the clips should have been intact.
  Bill B.
 
Aha! Set the record mode to sound on sound. Stopped recording after the fourth punchout and before the end of the loop and got a fifth take lane with just a tiny clip.  This one contains 768 samples after recording 4 full loops. That is the same number of samples by which the fourth take is delayed (3*256).

So assuming this is still a bug will this be fixed for X3D or X3E ?

So DeeringAmps has created a new thread saying that this isn't fixed. Rather than split the discussion over two threads I'm responding here. Could anybody do a test case for this please if it still exists in X3D, here is an example of a test case (totally unrelated!!). We need exact steps to reproduce.... Let's just make this totally clear... Supply screenshots but only if necessary. Make sure you supply all steps starting with "Start Sonar X3d, create new project". Got to be extremely detailed... thanks...
 
TEST CASE EXAMPLE:
 
STEPS FIRST ISSUE

Turn on 3 USB MIDI devices (such as keyboards), each MIDI device has it's own channel (say 1 + 2 + 3).
Start Sonar X3D
Create new project
Insert 3 Dimension Pro softsynths.
Assign an exclusive sound for each softsynth.
Assign a single MIDI device to each softsynth track, making sure the MIDI input channel is specifically set correctly. i.e. If it's a Yamaha keyboard on channel 1, assign Yamaha Keyboard ->  MIDI ch.1.
Check to see if instruments play correctly.
Save the Project.
Close Sonar X3D application.
Turn off one MIDI device.
Start Sonar X3D
Open existing project.
Now play the MIDI controllers.


EXPECTED...

a) Some warning that MIDI devices have disappeared.
b) All three MIDI tracks have maintained their values, however the missing device is flagged up in some way.

ACTUAL...


The track with the missing MIDI device seems to have had the MIDI input changed to one of the other MIDI Input devices (which is weird).
Another MIDI Controller will have it's value changed for no reason whatsoever.
A third MIDI Controller will have the value persist.

I realized why this isn't a problem for me. I never punch within a loop because I rarely quantize audio, so I usually need to add crossfades for any "punched" clip inside a loop. I record the "punched" part on a separate track while looping, then when I have the part I want, bring the clip into the track where a section needed to be replaced and add the crossfades.
 
Sure, it would be nice if you could have a punch inside a loop. But I MUST be missing something, because it seems to me there are several ways to accomplish replacing a section inside an existing track, so I don't see why this would be a deal-breaker in terms of working on projects.

Nevertheless if this is a bug I'm keen to reproduce. There's always a million ways to skin a cat I agree :)