Well, it appears to be only related to the BOOLEAN array item. Removing that from the original array leaves a perfectly sorted array as far as I can see now.

Last addition: I meant sort() where I used asort(), but the result is the same....

  IMO this is not PHP problem but the way the compares are done. You have to master the type juggling to see that the result is correct. I have reduced your testcase to this :
<?php
$arr1 = array("a","b","c","d","4",5,4,"true","TRUE",true);
sort($arr1);
var_dump($arr1);
?>

The output is :
array(10) {
  [0]=>
  bool(true)
  [1]=>
  int(4)
  [2]=>
  string(1) "4"
  [3]=>
  string(4) "TRUE"
  [4]=>
  string(1) "a"
  [5]=>
  string(1) "b"
  [6]=>
  string(1) "c"
  [7]=>
  string(1) "d"
  [8]=>
  string(4) "true"
  [9]=>
  int(5)
}
It may look strange - why (int)5 is after all the strings. This is because "4" is lower than (int) 5, "4" is before "true" and "true" is before 5. The first 2 are obvious, the third one is not. But it is ok. It's better not to mix types in the array. If 5 is changed to "5" then "5" goes right after "4".

Bogusifying

I have to disagree with you. Indeed, if it is the array you tested, these results are correct. Fill an array with multiple instances of identical values like the ones in the original example, and the boolean trues (output as '1') are distributed in a unpredictable way across some -not all- of the subsets of other values. Example:
a a a a 1 a a 1 a a a 1 b b b b b b 1 b 1 1 b b b  and so on.

I agree with you using multiple types in an array can be tricky, but the results I got just should not occur. Another (unrealistic imho) option would be to just say: don't use mixed type arrays, but I would expect this is not the way PHP should be heading.

Following on from my comments in Bug #21728, I've analysed this sort tooo and, believe it or not, this is actually a correct sort for the default SORT_REGULAR sort type!!  This is because of the non-sequential order that comparisons are done, and the automatic type-conversion that occurs for those comparisons.

In this case, all non-null strings are cast to (bool)true when comparing with a bool, so that true=="a" and true=="b" and true=="c" and....  This gives you the strange result you see, where your genuine Boolean true values can be distributed anywhere within your otherwise correctly sorted strings.

Producing the same breakdown for (a slightly shortened version of) this array as I did for the arrays in #21728 gives:

  'a'  : 'a'   ==>  (string) 'a'  == 'a'
  'a'  : true  ==>  (bool)   true == true
  true : 'a'   ==>  (bool)   true == true
  'a'  : true  ==>  (bool)   true == true
  true : 'a'   ==>  (bool)   true == true
  'a'  : 'a'   ==>  (string) 'a'  == 'a'
  'a'  : true  ==>  (bool)   true == true
  true : 'b'   ==>  (bool)   true == true
  'b'  : 'b'   ==>  (string) 'b'  == 'b'
  'b'  : true  ==>  (bool)   true == true
  true : 'b'   ==>  (bool)   true == true
  'b'  : true  ==>  (bool)   true == true
  true : true  ==>  (bool)   true == true
  true : 'b'   ==>  (bool)   true == true
  'b'  : 'b'   ==>  (string) 'b'  == 'b'

And yet another surprise -- every comparison of neighbouring elements in that sorted array is an equality -- no single comparison yields a less-than result, even though the 'a's are all correctly sorted before the 'b's!!

I think the moral here is not to use the SORT_REGULAR sort type when you have mixed-type elements in the array.  In this case, you might possibly get an acceptable result by specifying the SORT_STRING sort type, as false would compare as "" and true as "1" -- only a problem if those values also occur naturally (either as strings or numbers) in the array.  The other option would be to use usort() with a callback that checks types before doing a value comparison.

But anyway, I agree, not a PHP bug -- more a curiosity of its design!

Cheers!

Mike

NOT a bug.