Yeah, theoretically we can do that, although I'm not very keen on the idea of maintaining yet another build of Python ;) certainly not for EPEL5...
Note, that one important thing to decide here what the dist-git solution will be. The EPEL5 python26 solution basically created new repos for all packages, called python26-*. That's viable for python27, since there's no python28 coming, but it's not a good solution for python3X. That's why I'd probably rather apply the same approach that we'll take for python3X in EPEL7 (whichever that will be).
Also, I'm starting to think about the technical solution (read: RPM macros) to multiple Pythons, since I really don't like the python26 solution from EPEL5. I'll put my solution in a proposal next week, so that everyone can comment on that, too.
Something similar should be usable in EPEL 6 for python27, but I realized that situation is a bit different, since python27 is never going to be replaced by python28, so there's no need to consider two 2X stacks. I have to admit that I have very little interest (and time!) for python27 in EPEL 6, so I'll leave that proposal to someone else.
As usual, all comments are appreciated!