Interesting points, I'll keep them in mind. I don't really have to worry too much about making old code work, so I'd not be too concerned with that. I'll probably start with Py3 because I don't really expect to rely on too much library support for the things I'd cobble together in python.
As far as unit testing goes, you are absolutely right. I unit test everything....I mean, I was taught TDD right out of the door at Uni, and though I don't exactly follow the methods strictly, I am at my core, a functional programmer. I want every last bit of code I write to do one and only one thing well. I, therefore, test all of those functions, no matter how mundane. But you know what? Even then, my test coverage on a good project, where I'm not just dicking around probably hovers about 85-95% coverage. There's just always some flotsam and jetsam that escapes the tests. First time I worked on a project with a team, I stressed my head off because of that very fact, until we did our first metrics review and I saw that I was actually ahead of most people....
And also, you'll find more bugs in Python3 libraries. They're being used less than Python2 libs. That, and the long tail of libraries that may never get moved to Python3. There's really a lot of reasons to not use 3, or like me, wait to see if it ever really overtakes 2.
A 3rd extra reason if you needed any more, is that almost all jobs in the field use 2.x. I tried to love Python3, but the technical reasons just don't make sense to migrate, and once you meet the coercion and vitriol of the Python3 community, you'll learn to resent its existence and them.
The future of Python2 is actually very bright, while 3's is in jeopardy. That's why everyone is so pushy about it, they lose their bet if it never gets over the hump. Being as 3.0 was released in 2008 and it's now 2015, I honestly think that answer is already here.
Using 2, then switching to 3 if it ever does overtake it makes a lot of sense and is the sensible bet. But 3.x overtaking 2 anytime soon is really unlikely, and library worth anything will be 2+3 compatible and dropping 2 support would just be asinine with the ~83% userbase it holds today.
Even if Python3's userbase doubles in 5 years, it'll still be under 50% of the overall Python userbase. And I think doubling its current usage would be overly optimistic. Python3 will either collapse, or split the community (already has to a degree) with someone forking Python2 for good. Pyston may be that fork, or a couple other contenders.
The situation is a disaster all around. For Python and the community. Companies in some cases now aren't putting new product down in Python because of this.
You'll be alright using 3, because no matter the final outcome you'll be able to go back to 2 without issues and vice versa. I only recommend 2 because you won't be missing any libraries if you use it, and if you want to do it for a job you'll be using 2.x anyway.
Python3's biggest purpose is giving people a reason to hassle maintainers to port to it. They bite on the political propaganda surrounding 3, that it's the "newest version", which for programming languages is not always in best interests of the user unlike an up-to-date web browser. Then when they find out x doesn't work or exist in 3, they badger whoever wrote a library for 2 to port.
Those people really need to port it themselves and maintain it afterwards. They don't, and it's just an ugly situation.
For example, you can build iOS/Android apps using Kivy. Guess what, can't build for iOS unless you use 2.7! Just lots of surprises out there for those who start off wanting the "latest version". It's not the latest version, it's a new, breaking language. If you end up doing much cobbling with Python, this may be of interest to you.
I have my doubts 3 will get over the hump, and just plan on waiting till the complainers turn into maintainers and 99% of everything is ported. Then I'll use Python3 if I don't find something else I like more before then.
As far as unit testing goes, you are absolutely right. I unit test everything....I mean, I was taught TDD right out of the door at Uni, and though I don't exactly follow the methods strictly, I am at my core, a functional programmer. I want every last bit of code I write to do one and only one thing well. I, therefore, test all of those functions, no matter how mundane. But you know what? Even then, my test coverage on a good project, where I'm not just dicking around probably hovers about 85-95% coverage. There's just always some flotsam and jetsam that escapes the tests. First time I worked on a project with a team, I stressed my head off because of that very fact, until we did our first metrics review and I saw that I was actually ahead of most people....