True. but I would not call it a race condition. We timestamp
everything with the time when a request arrives, not when it is
processed, unless specified otherwise (datetime.now() instead of
request.now)

True. But that does not make it a better idea. Also, datetime.now()
should be consistently replaced with datetime.utcnow() because using
anythign else than UTC data internally is problematic for various
reasons. See the discussion on that topic in various i18n/l10n
libraries such as babel / pytz.

True but I believe we never do that in web2py. It is also true that
nothing prevent the user from doing it but the same would be true with
other frameworks.

You're not doing it, a user might be doing that by accident or because
he things it should work. This problem does not exist in other
frameworks because besides web2py I don't know a single one that does
this sort of execfile() + namespace thing or uses any other kind of
throwaway modules. As soon as a single reference leaks from the
execfile()'d namespace you're in big troubles and due to the open
nature of Python this could happen very, very fast.

Yes but because all relevant application code is executed within a
context and there are no references outside the context to stuff
inside the context, when a request is completed, the context is
deleted and everything should be garbage collected.

That depends on two things. First not having a reference leaked,
which could happen with abstract base classes and other stuff that
uses registries or steals non-weak references. Also and more
importantly, the file descriptor limit is very low and the majority of
Python implementations will only collect that on the GC run (always,
no matter where references are). Say you're opening three files per
request and you have more than 100 requests/sec you could lose all
file descriptors that are available before the GC even thought about
running.