With manual offset = 0 and 'Use Reported ASIO Latency' unchecked, you are measuring the full, actual, roundtrip latency.  Those settings are what Sonar uses to adjust (nudge?) your recorded audio to counteract the effect of latency.
 
The reason things line up better when 'Use Reported ASIO Latency' is checked is because Sonar is moving your recorded audio by that amount to compensate by the specified amount.
 
In my example, the reported latency is greater than actual by 28 samples according to measurement.  If I test further and find this to be consistent, I could enter -28 in the manual offset box to correct for this overestimate from the driver.
 

I think by using the internal loop you are possibly bypassing the converters. The signal stays inside the interface as digital. Therefore the lower figures. So the actual figures would be with the external loop as that represents you hearing the signal in your monitors or headphones and playing along with it to overdub. 
 
Here's the screens I think you wanted Bob, I don't think we are wandering off the topic at all as what I'm ultimately after is "what makes one driver better than another" ? 
You might be on to something as notice the Scarlett in and out is close but the Tascam is way out of balance. Possibly this is those "hidden" buffers they talk about that fool your DAW and give false readings. 
 

The internal vs external loopback is very likely to be a signal tap prior to the D/A converter, that is the 70-76 sample difference and pretty consistent between tests.
 
What confused me was with the "reported" 319 samples. Since it was off on the first run, I would expect the second to be offset by that amount, but for both tests (internal and external) the offset was 191 samples. Any insight into why this would be? The delta is 128 samples, which also happens to be the buffer that I was using at the time. I am not sure how this all "plays together" now.

Interesting. Any chance of a Screen Shots? Makes it easier for my slow brain...
For me I ran the test a bunch of times and the results stayed the same each time for all 4 interfaces I tested with the exception of the Behringer. It was just a little different each time but that was to be expected using WDM drivers. 
In the past I tested a Creative Audigy II card that was like that. Every time the test was different and sometimes by a lot. Even though they claimed ASIO drivers, they never worked and you had to use the WDM driver. What I'm seeing is WDM drivers are going to give you real bad timing issues. 
 
Try it with any of your's if they allow it. Switch to WDM mode and run the same test. It was odd that the Scarlett doesn't support WDM mode.  

FYI - I tried switching to WDM/KS for the Tascam 16x08.  Not good at all.  I can't even get it to do 48K via WDM.
 
 

M-Audio Fast Track Ultra, 24bit/48kHz 
loopback 1 - 128 samples
loopback 2 - 64 samples
loopback 3 - 960 samples
all were 1 sample early
 
The wdm and wasapi numbers were 200-500+.  WASAPI got exponentially worse when the buffer size was increased.
 

I've never fully understood WDK mode. I used to think it was installed as an option with your ASIO drivers. Might be true of some drivers but obviously not all of them. The Tascam us1641 seems to let you switch but not my Focusrite. 
My Card Deluxe interface looses the SPDIF option if you switch to WDM mode. ANd you also won't have the control panel. So seems WDM mode is a very pour option as a driver even though Cakewalk recommends we try it if ASIO doesn't work. And asio4all is a WDM wrapper so this would explain why it is a crappy option most times too.
 
I think unless people are willing to run this test when they say things like "I'm using WDM mode with out any problems" I think they are unaware of what might be happening to their tracks syncing up. Some might not even notice. For vocals and lead guitar  2-3 ms offset might not even bother some people. It bothers me. 
I gave up on recording with Cakewalk Home Studio back in 2004-5 because it sounded way out of sync all the time. Turned out I was correct but it was my Creative Sound card, not Cakewalk to be blamed.
I returned to my Atari and my Yamaha MD8 because it synced up perfectly. 

Here is a screenshot of the above and I re-summarized it below:
 
 
Test Setup: X3e, Saffire PRO 24 DSP, 44.1/24, 128 buffer, 319 sample latency (reported). Did a test with both internal and external loopbacks; the first set without any offset, and the second set using ASIO reported latency.
 
Delta between Internal and External loopback is 70 samples in both cases, most likely due to bypassing the D/A converter for internal loopback.
 
The bottom two runs use ASIO reported latency, which is 319, but both shift left by only 191 samples. The "delta" for each is 128 samples... the size of the buffer used, so not sure how to best understand this (why would buffer come into play here?). I am not understanding how the 319 and 128 are "fitting together," I think.

Thanks, Johnny. Yes that is exactly what I was looking for.
Some difference in I/O latency makes sense. Input latency involves only the interface(at least it should).
If this is very low, it suggests that the interface is efficiently handling the A/D conversion for incoming signals.
The output latency is somewhat more relaxed, allowing the CPU to process effects, etc before handing the signal back to the interface for the D/A conversion. I get that.
The original drivers for the AKAI had an excessive output latency, similar to your Tascam, and it would lose sync after a minute or two.
I think the key here, and the premise of your original post, is that the numbers need to be reported correctly to Sonar. A few samples is no big whoop. Several hundred, and you are looking at a few ms, phasing issues, etc. I'm just glad I don't have to write the code for this stuff

Any result to this test that reveals latency Sonar fails to automatically correct for is probably down to the device driver not reporting the true latency. Many, maybe most, USB interfaces have an additional buffer built into them which is often called a "safety buffer". Some drivers fail to report this back to the DAW, hence the need for a human to step in and adjust the settings.

I've seen claims, complete with data, that one or two drivers/interfaces seem to report back latencies that are all over the place and bear little relation to the buffer settings (e.g. decreasing the buffer results, at some settings, in the driver reporting longer latency).

Just to add to the data, with a patch cable between interface output and input, at 48 sample buffer size I measure 4.8ms round trip latency at 24bits/44.1K. Sonar's preference setting agrees with that and Sonar places the loopback audio spot on give or take a sample or two.

Switching to 48KHz the latency doesn't change much, just a tenth of a millisecond. RME explain this is the result of the hardware needing some time to operate, and that time can't easily be reduced with current technology. The hardware and interface software needs some time to do its job so there's a point at which lowering the driver buffer size will make little or no difference.

For those using tablet or phones and can't see my sig, interface is an RME UFX connected via USB2.