I checked things a bit. I _think_ it's an artifact of Nim code compiling each nim file into a separate .c file. After that point the regular C toolchain takes over.
c gets compiled to .so, and then .so files get compiled to the final binary. Anyhow, at the .so level, there's some symbols exported; mainly for things like global variables, or for (non-generic) functions. But nothing like C structures. The .so files are already 99% machine code by that point. So anyhow, in the working version, the .so file for types.nim has got an exported link symbol for "toFoo" that takes an int and returns an int. In the not-working symbol, there's no link symbols that can be exported. ie, there's no useful .so file that could be produced directly from types.nim So anyhow, that kind of C compilation semantic probably gets reflected in how Nim does parsing of things like generics, to be able to compile the .nim files separately to C, and then link them together again to get to the final binary. I think it's something like that, anyhow. Probably the compiler could be updated so that it follows rules that aren't constrained by the C compiling and linking process. But that would probably also make compilation take a lot longer; something like whole-program type inference would need to take place, or something like that.
