I completely agree. Microsoft would be smart to sell it separately, like Sony are. I just don't get Kinect. They are losing so many sales because of it. If it weren't for that, I might have considered the XB1 first before the PS4. I'm sure a lot of people are thinking the same way.

But the situation you are describing is Microsoft footing the bill for Third Party to develops these features? Which is the point I made in my very first post in this debate. It's easy enough for Microsoft to pay Third Party to develop exclusive Kinect features but it's another to get Third Party to actual bother to spend their own budget on said such Kinect Features, that’s the problem.

Once that code is generated, they need only implement it in a future game.

For instance.  If Microsoft paid for the Kinect features in Skyrim, so what?  If the features Bethesda implemented, such as voice commands, proved popular, then they need only implement the code in their next game.  Bethesda owns the code.  There's no cost to reusing code.  Sure, you might tighten and clean the code, but overall, as long as the code was 100% functional as it was originall implemented, then it's going to work.

I highly doubt there is a significant difference between the API for Kinect and Kinect 2, since you're quite literally just waiting for Kinect to tell you whether or not it received a desired/specified command, or in the case of gesturing, the x, y coordinates of the cursor.  It isn't much different from coding for a mic or game controller. 

The Touch-pad on the PS4 has two major advantage over Kinect 2. Firstly the Touch-pad is a control method which has been used for a lot longer than Kinect and has already been fully accepted. Laptops have been using Touch pad as alternative to the mouse since the late 1990's. So any game developed on the PC which uses the mouse/Touch-pad is now a lot easier to be ported over to the ps4 in terms of controls. Ports of existing Tablet games are more a possibility now for PS4 and maybe even of some of the Wii U games touch based control could be ported over as well.

The second and the most important differences between the two is that the Inclusion of the Touch-pad is not a massive cost expense compared to Kinect. So even if Third Party ignore the Touch-pad it's not that much an issue to the PS4 in terms of their direction or an added cost to PS4 consoles. Kinect 2 on the other hand has forced Microsoft to go with a weaker system and 100$ higher price. Making the Kinect 2 mandatory at the cost of power and price shows Microsoft are making a big deal over Kinect 2 features. So if the Third Parties ignore Kinect it's would a massive problem for Microsoft to justify the Kinect 2 with only their software to showcase it.

Even with an existing made code it will take time to implement and test said feature for every game it used on. With the tightness of budgets and especially in the terms of getting games out on time. I don't see much demand on the part of Third party to bother with said features which have already been given a some what lukewarm demand from the majority dedicated gamer.

The time it takes to implement is equivalent to copying pasting code, because that's exactly what you're doing.  If you're smart, you've put all your code for such purposes in a library and the only thing you do is make a reference to that library in your code.  Since you've already used that library, you know it works, and if you're using a good IDE, it'll tell you if your code is broken before you compile it.  So, geez oh mighty, it isn't that big of a deal! 

Yes, you will need to test it, but it isn't as if you should expect broken code.  Fact is if you've done everything correctly it will work exactly as you expect it to.

Have you ever coded?  Have you not re-used code?  Is coding a such a challenge for you that once you get something to work properly, you're unable to get it to work properly again?  I'm confused as to how or why you see this as such a big challenge, because it isn't.  Smart coders code once, and reuse many.  What do you think a game engine is?  A series of code people copy and paste into a single document?  No!  It's a series of library files that you reference in your code and make calls to those library files. 

I don't think it will be widely used but it will get more support than the original did. I just hope developers don't use it in gimmicky ways or just for the sake of it. Use it if necessary.

I think it will put them in a Nintendo situation. It will only be used for first party Microsoft games, and if they focus too much on it, third parties will avoid it because it does require too much extra coding for multi-platforms. Initially they will get a lot of support, but 2 years from now it will be a curse

Even with re-using code, it still takes time to figure out how to apply it to new games. The more complex the input method the more testing is needed. For example is it physically possible to make certain gestures one after another in the allotted time. Does the game need to be slowed down to allow for gestures to be completed or commands to be spoken in between the actions.
It's not just receiving the inputs from Kinect, it's also tailoring the game to an extra input method, and balancing the gameplay between both. A lot of developers don't even bother anymore to optimize a game for mouse use on PC, certainly those APIs are mature enough.

Sure some tacked on Kinect use is easy to add in the game, I wouldn't expect much from it from 3rd parties though.

In some game types, yes.  Game types that require timed gestures.  Not all game types would require that however.  Skyrim's voice commands, for example, allows you to speak at any time.  It's an open mic, so it Kinect is waiting for you to say something.  You just have to say it and when you do, the game interprets the input as a command.  It looks for a gesture movement, and if it sees it, it interpets that gesture as the command.  There's no timing involved, other than the gesture itself must be executed appropriately.

Yes, you could have situations where the numbers and complexity of moves would require tight timing.  I'm not arguing that you can't have situations where you need to tune the input actions to the gameplay.  But that doesn't necessarily require significant resources to accomplish.  Coding is what requires significant resources, not tuning.  Coding requires knowledgable developers, time, and money.  Tuning requires beta/user testing.   Reusing code signficantly reduces coding time, if it didn't everyone would write their own gaming engines from scratch every time they wrote a new game.  That doesn't happen, because it's absolutely proposterous. 

Trying to suggest that tweaking code to tune the game play requires a significant investment is a stretch.  The only instance where that would be true is with a game where the input method was solely Kinect and timed events were the rule not the exception.  I have no doubt, for example, that Dance Central required a significant amount of time to tune initially.  However, once they had the timings down, that code got reused with Dance Central 2 and now with the new Disney Fantasia game.  The tuning required would have been miminal after that initial tuning as necessary for the performance improvements in Kinect. 

So once a developer builds the code and tunes it, it can easily be ported to other games.  So I, respectfully, disagree with your premise.