My main concerns would be:
From an organizational standpoint, changing to this structure could be incredibly disruptive of current projects. (I've seen this happen at least twice and clients were very unhappy.) Is there any gain which could offset this disruption? This type of change would affect deadlines, would affect ability to deliver the product (some people are bound to end up on projects they are not very familair with) because of having to learn the new project. It is also incredibly risky as some things might get lost in the shuffle as people currently assigned to do them move to other projects. What would be the plan? Is there a way to do a phased change?
If there is less cross-pollination, will you be in trouble if someone key on a project takes another job? Developers tend to move around. Having fewer people know the details of projects could be costly. If we are talking project teams of 5-10 that might not be an issue, but if the teams end up as 1-2 on a particular project it could be.
If you silo people into specific product lines, are you limiting their ability to gain new knowledge (a must have for most good programmers) and thus pretty much forcing the best ones to leave to keep up their professional qualifications? The more projects you have using older technology, the worse this could be.
How easy will it be to transfer to other projects? Once you get to be expert in one project, the chances of moving around become much reduced. So if devs feel you are hurting their career paths, they will leave in droves and you will lose alot of the current knowledge. At the very least you will need a plan to allow transfers to other projects and a way to get past the "I can't give him up because he is the only one who knows..." issues. Career progression is important, the more project specialized people are the harder it is to move up as well. You need a plan to handle it. You might consider moving 5-10% of the developers each year and making it a requirement that everyone has to be allowed to change product lines at least once every 5 years. This could help force the cross pollination, give people a chance to get new types of experience and keep the bulk of the team relatively stable. The ramp up time should be figured into the project plans because you know you will get some new developers every year. It would also help keep managers from relying too much on one person as they know he will evenetually be transferred. You might also make sure people can apply for new openings without having to have approval of their current boss (to prevent people hoarding).
I would ask your boss what he expects to gain that would offset the possible problems (I'm sure that being in the current situation you can think of more than I could. You can also probably see what the benefits might be.)
You also need to consider that you might have specialists who need to remain cross-functional no matter what. Or were you going to hire 7 business intelligence specialists (1 per projet) instead of the 2 you have (as an example). The best bet might be to do a hybrid organization where some are siloed and some are not.
You could even do a cost-benefit analysis that quantifies the risks and rewards of both possibilities so that he can see what the impact would be.