1."compare" should result in "true" but gives "false" instead. What is wrong?
2. "split at" 'empty' results in a list ("empty-string", 1...[list]...); doesn't make sense. The result should be "(1)" to avoid always to remove the first item for a clean list.
or do I think wrong?
You use text blocks for comparison. The text "0" does not equal "0.". Likewise, "a" does not equal "A". Likewise, "0" does not equal "00". If you use a math comparison block then "0" is the same as "0." and like "00".
That is exactly what I want to do: comparing text blocks, not numbers. Don't you see the conflict between the statements?
Yes you are right.
In fact, this block does not work like a text comparison. It works like a math block.
It's an error.
There are more text blocks that cause problems. It would have to be put together to make it easier to fix.
According to
http://ai2.appinventor.mit.edu/reference/blocks/text.html#compare
the 0. not equal 0 comparison should come up true, but it comes up false.
I agree this looks like a bug.
The extra empty list item at slot 1 after a split at empty text has hardened into a feature by now, and code is out there to work around it.
Thank you for having delt with!
These tests of '>' and '<' can be reduced to three basic rules:
None of this, however, explains the <> operator action reported above by the OP.
I am assigning to @ewpatton the original complaint:
Why does text compare of "0." (not equal) "0" return false?
I don't recall this ever being mentioned as a bug, and the text compare (not equal) option is recent, so likely to be buggy.
Technically, one could consider a string terminating before another as terminating with the NUL ascii character (0), which is less than whatever the next character in the other string would be.
This is a bug. After reviewing the code, the not equals comparison produces the following YAIL (simplified):
(yail-not-equal? "0." "0")
But the problem is that yail-not-equal? actually does a bit more than simply comparing two values, because it also includes the type coercion logic. If the two values fail to compare, App Inventor will try to parse them into their numeric forms and compare again (which is wrong in this scenario). It would be more appropriate for the block to generate something similar to:
(not (string=? "0." "0"))
which is equivalent to the blocks not compare text "0." = "0".
Thank you!
One other thing to mention is that it's not quite an ASCII based sorting as far as I know. I believe that internally the string comparison functions ultimately are underpinned by Java's string comparison logic which can be locale dependent and uses the Unicode character code points, but the logic is effectively the same as @ABG outlined.
What is the same cannot be different. This is against logic. 
Fix for the string != check is now pending review.