Looks like the behavior on Linux is correct according to TR10:

http://unicode.org/reports/tr10/#Multi_Level_Comparison

In Unicode collation order "J" should sort before "z" and after "a" so this return value is consistent with the documentation.

The implementation on Darwin uses a hack if the elements are ASCII to use normal ASCII conventions, which results in this behaviour. It seems that this optimisation has caused problems elsewhere as well:

ef974af

I wonder if the right thing to do is to ditch the hack altogether and have consistent behaviour on all platforms.

Comment by Jay Buffington (JIRA)

Another example:

# on Darwin
  1> ["A", "b", "C", "d"].sorted(by: { $0 < $1 })
$R0: [String] = 4 values {
  [0] = "A"
  [1] = "C"
  [2] = "b"
  [3] = "d"
}


# On Linux
  1> ["A", "b", "C", "d"].sorted(by: { $0 < $1 })
$R0: [String] = 4 values {
  [0] = "A"
  [1] = "b"
  [2] = "C"
  [3] = "d"
}

This should've been fixed with #13877

Lance (JIRA User) can you verify set to resolve if so?

edit: Terminology surrounding "verify" and "resolve", grammar

This was fixed for 4.2