I'm not a huge fan of 2.* but I guess that is up to you. :) It depends on how quickly you have new releases and how much you'll be changing between minor releases.

As to your "what should I do where" ... the short answer is that Composer will take all of the dependencies in the tree and try to resolve them.

So if you require 2.0.* in one, and 2.* in the others, it doesn't matter *which* projects required which, the only thing that will ever install is 2.0.* since all of the other constraints are more permissive.

In general, I'd say libraries should be more permissive and projects should be less permissive. And by projects, I mean end-user applications. So you could require 2.* across the board, but the problem comes in when you introduce something that people rely on in version 2.3.0 ... anything that depends on that functionality should change to something like >=2.3.0,<3 ...

This also assumes no BC breaks ever in 2.* ... 

Anyway, it is really up to you. :) I'd say start tighter and then see how things progress. If it is 6 months to a year before you get to 2.1 releases it won't have hurt to stay at 2.0.* during that time and at that point 2.1 might be a big enough change that people will be happy to stick with 2.0.* for awhile before making the jump.