So 3.2/5 actually seems like pretty strong support. First note that a definition is a source code construct, not an object code construct, though clearly there is a very close relationship. 3.2/5 is saying that it's okay to have multiple definitions of non-static function templates, and that furthermore in such a case it must behave as if there were only a single definition. If a function had different addresses in different translation units, then that is not behaving as if there were only one definition, at least in my reading.
This is especially true since a function pointer can be passed as a non-type template argument. Such arguments must be constant and must be the same for all translation units. For example, a string literal cannot be such an argument precisely because its address varies across translation units.
Whether or not all the requirements are met will depend exactly on the context of the multiple definitions, since they deal with things such as name resolution, etc. However, they are all "run-of-the-mill" requirements that are of the "of-course" type. For example, a violation of it would be something like:
file1.cpp
static int i;
// This is your template.
template <typename T>
void foo() {
i; // Matches the above i.
}
file2.cpp
static int i;
// This is your template. You are normally allowed to have multiple
// identical definitions of it.
template <typename T>
void foo() {
// Oops, matches a different entity. You didn't satisfy the requirements.
// All bets are off.
i;
}
I know that multiple definitions are supported in Linux via weak symbols. In fact, on Linux the Lucking example fails to fail precisely because of this. I left a comment to his answer asking for platform. At link time, the linker will throw away all instances of a weak symbol except one. Obviously, if the instances aren't actually the same, that would be bad. But those requirements in 3.2/5 are designed to ensure that the instances are in fact all the same and thus the linker can keep only one.
ADDENDUM: Dieter Lucking now says that he had a compilation problem, and it in fact does not fail for him. It would be good if someone familiar with the internals of Windows DLLs could comment here, though, as to how Visual Studio handles this.