Quite handy how? If you want to better structure in your project, simply use folders and/or break your modules up into sub-modules. Eg:
foo.nim
foo
|- bar.nim
|- baz.nim
# foo.nim
import
foo.bar,
foo.baz
export
bar,
baz
import
foo # imports both bar and baz (and anything else foo adds)
import
foo.bar # imports only foo's bar
You can also use include instead of import to divide large modules (for sanity and exposure control).
I would not be excited over multiple modules per file, mostly because I've seen what a mess the Julia language has made of it. They're so happy about the fact that modules and files are independent of each other that you can't get a consistent recommendation about how to actually structure your code, or even good documentation about what files Julia is going to look in for what code.
Having enums in their own namespaces sounds nice, but having those namespaces be modules sounds kind of heavy-handed.
It's come handy a few occasions for me -- while just casually thinking about the system and hacking around without having to jump around like a monkey between files. Another area where this seems to shine is with code generation, albeit it's not that pressing in Nim due to macros.
The way I see it, modules are just a logical grouping of types and functions. Forcing a module per file is akin to forcing a method or data member per class (reminds me of the mess Haskell is in when it comes to unique member names). IMHO, anything that can be abused will be abused but that shouldn't prevent languages and tools from giving programmers more freedom.
If you want to separate your code to two files but import them at once - use include
Yes, it's a good possibility, multiple modules per file give quite the opposite possibility, together they make logical structure of a program independent of storage.
SQLite amalgamation is useful in c because there you have to link libraries
Yes, you have much more need for amalgamations in C, in Nim there's no trouble with compilation. But handling just one file, when don't need to edit it, is of course more convenient. Any way, it's an example of usage. The point is more freedom for a programmer in structuring code. About that picture - I don't see how PHP gives much freedom :) (inconsistency is not freedom).
Lots of non-C family languages allow more than one module per file; Ada, one of the influences on Nim, and the ML family of languages, which have functions over modules (confusingly called functors, which often mean something else in FP languages). They even have locally defined modules, and OCaml (an ML) has first class modules, which can be packed and then passed into functions: http://caml.inria.fr/pub/docs/manual-ocaml/extn.html#sec230
It's an interesting idea, but it would be a big change for Nim. IMO, big changes in Nim should mostly wait until after 1.0.