From a brief look over both your code and Lifepower's, I have these comments.

In your Encrypt and Decrypt methods, you are setting Result to the length of the input string, but inside the loop you overflow the buffer allocated for Result in the last call to Move by up to seven bytes (your last Move is always the size of TBlock64). What you should do is set the length of Result to be the next highest multiple of eight over the length of Input. This is easily achieved with the following
Code:
l := (Length(Input) + 7) and (not 7);
SetLength(Result, l);
Edit: Incidentally, the Pascal code linked from that Wiki page does the same thing (in a different way). I'm not sure why you didn't use that code in the first place.

Lifepower's latest version makes a few assumptions about the strings which is why it does not work with ansi or wide strings.

This line
Code:
 // Step 3. Encrypt source string.
 Move(Source, Result, Length(Source) + 1);
is not the correct way to copy a string. This is the primary reason why this routine will not work with ansi or wide strings. Using Result := Source will not work with ansi or wide strings either, because you want Result to be a unique copy of Source (because the Result copy gets modified). Hence you should use a function that generates a unique copy of the string. I believe there is a UniqueStr() function in the RTL or something similar.

In CipherDataXTEA, the loop will not execute at all for strings with less than 8 characters. It will also not encrypt any remaining bytes after the last eight-byte block. The same goes for DecipherDataXTEA.

Also, and this might affect both, I believe that the C >> operator is a logical shift (bits fall off the end) and the Delphi shr operator is an arithmetic shift (bits wrap around). I seem to remember we found this when porting Quake 2 to Delphi.