Just to play devil's advocate, you might be able to handle this by hacking types through Erlang's pattern matching syntax.
Thus, you might have a function assign_activity(("KeeferUser", user_no), ("KeeferActivity", activity_no)) and rely on the compiler to match the "type" in the first field of each tuple you pass. It's not pretty, but it is possible.
There are plenty of ways to skin that particular cat, and languages exist and are successful without modules or namespaces or classes (like C). It's just a question of whether or not the proposal in the article is an improvement upon anything, and I think it's reasonable to argue that no, it's not; people added those features to more recent languages because they solved real problems. Replacing explicit, required, rigid categorization with optional, flexible categorization isn't necessarily a win: it could just mean that people don't actually think about the problem very hard, and you end up being unable to find all the things related to X when you actually decide you need to understand how X works, because people didn't bother adding in the "X" tag in the function metadata to everything related to X.
C has modules all right. A .c/.h file pair is essentially what many other languages call a module, and have all the problems that the modules in Joe Armstrong's fibonacci example also has.
Thus, you might have a function assign_activity(("KeeferUser", user_no), ("KeeferActivity", activity_no)) and rely on the compiler to match the "type" in the first field of each tuple you pass. It's not pretty, but it is possible.