Then there's .NET's "give classes and namespaces different names". Still, any resulting clashes are restricted inside the library and can be avoided by simply using OpenTK.Math; in affected files.

Not true, see above.

In other words, OpenTK.Math caused a constant and irreversible namespace conflict with System.Math. Weighted against a potential conflict with a 3rd-party library, I think the conflict with a system class is much more significant.

So, the only place where we face the problem is inside the OpenTK namespace/library. Which means half of my statement still holds. But you're right in that, I can't fix it the way I said. I have to specify either OpenTK.Math or System.Math every time.

Now, suppose you're a postman delivering into a building that houses two guys with the same name/surname. In order to make your job easier you certainly don't shoot one of them and deliver all the mail to the other guy's box. But you could ask one of them to tell his mailers to add additional info to his address (apt number).

No math is necessary to move to another assembly, a solution may be provided by nythrix, create a namespace to avoid ambiguity OpenTK.Calc.
This certainly seems the best solution and what is done in XNA should not influence at all in this or another open source project.

Having math in a seperate assembly would be a benifit for games that uses a network server.

It is rather handy to have access to the OpenTK math on the server, a place where you don't need any kind of graphics or openGL (in fact on a headless machine that may not even have X ). It would make it easier to create simulation components that use OpenTK math that get shared on both the client and server (player/shot positions etc..). Using a third party math lib would make it harder to take the results of said shared components and use them with OpenTK drawing code on the client (i.e. my player sim class on the client feeds it's computed position directly into the drawing system, and on the server it just tracks it in a state).

Math may be heavily used by the graphics, but it's also useful for other things that are totally separate from a drawing app :)

I understand that a minimal OpenTK could be built for the server (using Mono), but that adds more setup cost to the server, and gets away from one of OpenTK's strong points, ease of use/deployment.

@the Fiddler:
Looks like as if you would have found the ultimative Math-solution. ;-)

@other:
Two things you can do to make it simple:
1.) build your own DLL from the Math-folder; or
2.) copy the Math-folder into your project, add "using OpenTK;" to your project and use it.
Where is the problem?

--
The most fundamental problem in software development is complexity. There is only one basic way of dealing with complexity: Divide and conquer.

My vote is for separate math dll. IMHO if one develop graphical engine/renderer, he or she would prefer to encapsulate opentk/opengl interaction. Client interface of such renderer use various math types to specify transformations and so on. Conventions like "client app should not use any opentk functionality other then math" is not encapsulation.
Writing a math lib specially for this interface is boring and unnecessary:). Building Math lib from part of OpenTK source is not very convenient and looks like a hack.