Lossless does mean identical. If it didn't, then information about the original would have been lost, hence a 'loss'.
 
I am more inclined to believe that there is a problem with Sound Forge or Sonar, or with the way the files are being compared, than to think there is actually any difference between the information in a WAV and the information in a FLAC correctly generated from that WAV.
 
In fact I'm not convinced the 'invert and sum' is guaranteed to null to zero because digital audio signals are not symmetrical around zero - 16 bit signals go down to -65536 but only up to 65535. A full amplitude sine wave, inverted and summed, would therefore sometimes sum to values of -1 rather than 0 - or any value in between, if you were running the audio engine at a higher bitrate.
 
So, the noise floor of over 100dB in that screenshot above could easily be attributed to this sort of numerical error, and given that the SNR of 16 bit data is under 100dB anyway, it makes more sense to me that this was introduced somewhere else along the line (eg. upsampling from 16 bit to 24/64/whatever).

someone above asked about the file difference, so i saw this:
 
song is 4:02 in length
wav  size 62,769 bit rate kbps  2116
flac         43,422                     1469
 
and I noticed that all FLAC files were a lower bit rate than wavs, which were all at 2116 kbps.
since bit rate = sample rate x bit depth x channels
2116000/24/2= 44083 sample rate (makes sense, 44.1k)
the same flac 1469000/24/2= 30604 sample rate (30.6k ?) but still showed 24/44.1k in an audio editor.
the flacs render at different bit depths... my album had bit rates of 1409 to 1661, so part of the compression algorithm must affect not only file size but bit depth calculations.
 

To me it's more an issue  of FLAC files not being read by as many devices as WAV files. If they sound the same then it's more about convenience when sharing projects or individual files. Is FLAC going to become a standard that is useful?

I made another test.
 
I downloaded the latest FLAC (version 1.3.1) and converted the ripped WAV file to FLAC using the standard default settings.
 
The decode window mentioned it was skipping an 'unknown chunk field "LIST"' in the WAV file.
 
I took that FLAC (1) file and converted it to WAV (1) then I took that WAV (1) and converted to FLAC (2) and then took that FLAC (2) and converted to WAV (2): 
 
WAV -> FLAC (1) -> WAV (1) -> FLAC (2) -> WAV (2)
 
I compared the WAV (1) and WAV (2) files and they were identical (The SHA-256 checksums were the same).
 
I could not find any info about the LIST chunk in the WAV or RIFF spec.
 
I ripped the original file from a CD using Windows Media Player (64-bit), it may have inserted that chunk.
 
 

I repeated the NULL test, this time using the exact same original WAV file in two track, sent to an AUX track with one inverted.
 
The results were identical to the WAV/FLAC test - about -100 dB error noise and then after about 48 seconds the error dropped out to non-detectable.
 
So it looks like there is something in Sonar itself that contributes to this.
 
I tried changing the dither to OFF and there was no real change.
 
 
 
 
 

Thanks for pursuing this...seems like a definitive answer.
 
Regarding Beepster's question...Microsoft has chosen FLAC as the preferred file format for Windows 10, and it's gaining momentum now that memory isn't as expensive as it used to be, and internet bandwidth is faster. MP3's patent is close to expiring, which coincides with it being less necessary, and although Apple will probably try to hold on to AAC, FLAC will continue to gain ground.
 
I think the main barrier to acceptance is probably "legacy" (fancy word for "old stuff") devices that don't support FLAC. Once a generation of smartphones can handle it, I don't see much future for MP3 except where space is at a premium.
 
Of all the file compression formats I always thought Windows Media was best at lower bit rates, but now even Microsoft has abandoned it. Also if FLAC gets more traction, it looks like Ogg Vorbis's day in the sun will not arrive.

I needed to make one more test. This time I used Sound Forge to create a square wave sweep from 20-20,000 Hz in 64 bit floating point at 48 kHz.
 
In Sonar I am using the 64-bit engine. 
 
I put the WAV file on two tracks, inverted one and summed to a buss. Put Voxengo Span on the buss in the 180 dB range.
 
This time the null was perfect.
 
Most likely then, the previous tests I showed with non-nulls had to do with 16-bit conversions from the original CD file. Plus the CD was 44.1 kHz so there were conversions in sample rate as well.
 
 

For the test, record a wave, export as flac, import and flip polarity then null test.If anyone says that test isn't perfect, I will have to try it myself to believe it.