One of the issues with letting the community know about the upcoming Mod API (and other development-related projects) has been the sheer number of places that information can be posted, often only to be read by a specific group of people in that particular community. In the interests of making life easier for everyone interested in developer talk, Mojang now has an official Minecraft Developer Blog!
What does this mean? Well, in the words of Warren "EvilSeph" Loo:
(The Developer Blog) will be our space to let loose and nerd out. Posts made by us will be technical and developer focused, ranging from technical write ups on a new feature to information on the Minecraft API and things surrounding it.
I am excited to continue working to bring useful and powerful resources to the Minecraft developer community! This blog and the Minecraft API proposal system is just the beginning of my work to better involve and support the Minecraft developer community.
In the interests of keeping developers in the Minecraft community as involved as possible, the new blog will serve as a repository for all things API, such as planning for meetings, getting feedback on the system, and progress they are making on it, to name a few. No longer will it be necessary to scan every Twitter account, website and other forms of communication to get tidbits on the Mod API - it is all centralized, so you need only stop by the blog to read about (and possibly help with) the Mod API.
I'd rather have Mojang enhance Minecrafts engine, such as creating support for colored lights (and I mean really colored lights, not that half-assed thing Notch put there in 1.8) and moving lights (like a move-able light emitting entity) and leave modding to modders.
Minecraft Forge is already THE Modding API, and there's no way Mojang will ever develop an API as good as Forge, both because Forge already has a lot of time in advance, and because of the coding skills gap between them. Anyone who sets up MCP and compares Mojang's code vs Forge's notices the difference.
In the end, all you'll end up doing is load Minecraft with more code, that besides not being used by most people (seriously, you can't expect a first release to beat Forge's history, and modders to just move from Forge to MC API just because it's new and ''official''), will be slowing the game down even more, which will affect low-end machine users.
Also, you'll just be wasting a release to give players something they already have, or give them a worse version of it, while doing what you've been doing since Beta 1.7: Waste a release to implement something that has already been done in a Mod, but buggier. And besides a buggier implementation of what has already been made, you're turning your amazing Sandbox game into an RPG.
(1.7: Pistons, already existed, 1.8: Villages, it's 1.3.2 and Millenaire's are still better; 1.9: enchantments: been done before; 1.2: jungles, cats: more biomes and more creatures? where have I seen that before?)
Also remember that not everyone wants an RPG. Minecraft gained popularity as a Sandbox game. If players want RPG features, more animals, more biomes, machines, there are mods that do that. Having those 'optional' features being there by default isn't as optional as it could, mainly on SMP (the fun part of MC), where other players can take advantage of them over players that don't feel like using them. Even mods allow to disable features we don't want from that mod...
You should just focus on making the game run on less CPU cost, and probably move some rendering stuff to the graphics card. Maybe use a greater version of OpenGL? with 1.1 it can run on machines from the late 90's, but no machine from that time has the CPU power to run this game, so it kind of defeats the purpose...
...Minecraft Forge is already THE Modding API, and there's no way Mojang will ever develop an API as good as Forge...
I haven't been following the Modding API discussion much, but my understanding was that it would replace Bukkit AND have the ability to enable and disable mods on the client-side to match what was running on the server-side. Meaning server operators would be able to run a vanilla jar file and thus update immediately instead of waiting a week for a Bukkit recommended build, etc.