Wikipedia defines software orthogonality as:

orthogonality in a programming language means that a relatively small set of primitive constructs can be combined in a relatively small number of ways to build the control and data structures of the language. The term is most-frequently used regarding assembly instruction sets, as orthogonal instruction set.

Jason Coffin has defined software orthogonality as

Highly cohesive components that are loosely coupled to each other produce an orthogonal system.

C.Ross has defined software orthogonality as:

the property that means "Changing A does not change B". An example of an orthogonal system would be a radio, where changing the station does not change the volume and vice-versa.

Now there is a hypothesis published in the the ACM Queue by Tim Bray - that some have called the Bánffy Bray Type System Criteria - which he summarises as:

1. Static typings attractiveness is a direct function (and dynamic typings an inverse function) of API surface size.
2. Dynamic typings attractiveness is a direct function (and static typings an inverse function) of unit testing workability.

Now Stuart Halloway has reformulated Banfy Bray as:

the more your APIs exceed orthogonality, the better you will like static typing

My question is: What is the evidence that an API has exceeded its orthogonality in the context of types?

Clarification Tim Bray introduces the idea of orthogonality and APIs. Where you have one API and it is mainly dealing with Strings (ie a web server serving requests and responses), then a uni-typed language (python, ruby) is 'aligned' to that API - because the the type system of these languages isn't sophisticated, but it doesn't matter since you're dealing with Strings anyway.

He then moves on to Android programming, which has a whole bunch of sensor APIs, which are all 'different' to the web server API that he was working on previously. Because you're not just dealing with Strings, but with different types, the API is non-orthogonal.

Tim's point is that there is a empirical relationship between your 'liking' of types and the API you're programming against. (ie a subjective point is actually objective depending on your context).