为什么MAC和Window版本之间存在Silverlight实现中的以下差异

Question

我正在阅读用于Windows的Silverlight实现和MAC实现之间的differences列表。可以找到HERE。

虽然有些差异显然与平台差异等有关。有些我只是想知道为什么它们会有所不同。如果有人对此有一些想法或实际具体信息，我很乐意听取您的意见。

以下是一些看起来很奇怪的事情，特别是我列表中的最后一点，这实际上促使我发布这个问题。

1. Char.ToLower（Char，CultureInfo） - 在MAC上使用当前文化而不是指定的文化。很奇怪，因为MAC可能支持多种文化（我没有MAC或者对它了解很多，所以这是我的假设）
2. 十进制/单一/ UInt16 / UInt32 / UInt64 - 该文档声明不支持上述类型，操作系统不支持它们，因此它们被“模拟”（我使用术语'模拟'松散，因为底层CPU肯定支持它们，当然不包括十进制。）
3. 双/单*无限属性 - 为什么这些属性会在不同平台上返回不同的字符串。现在我并不是说人们应该使用字符串表示进行比较，这将是愚蠢的，但为什么要使它们不同，是不是只是寻找不需要存在的可移植性问题？或者这更像是一个特定于平台的用户体验问题，MAC用户希望看到无穷大符号而不是单词？
4. CultureInfo构造函数 - 在Windows上，如果将无效的区域性字符串传递给构造函数，则抛出ArgumentException，在此文档中，CultureInfo将初始化为当前区域性，并且不会引发异常。

现在，鉴于您的代码是根据通常理解的最佳实践编写的，因此这些都不是严重的差异。但是，我想知道为什么我认为可能不正确的事情是行为合同的一部分，虽然在.NET中不明确，就像我将无效的文化字符串传递给构造函数时所期望的那样，并不能提供一致的行为平台，这似乎是相当随意的，只是在没有充分理由的情况下寻找可移植性问题，或者在那里？