If Microsoft does go this route, I am all for it, but they would need to be careful with it too.
Thing is some of that is already possible. Parallel job steps can be done with some workarounds. And loops can be done with SSIS or similar workarounds to parallel job steps. Sure they are not ideal and require some tweaking to make work right, I think that it is a safer option than monekying around with the SQL Agent.
One of the big risks with changing the SQL agent (in my mind) is you are going to need to do several pieces of updating. Maintenance Plans will need tweaking to work with the new SQL Agent, all existing scripts for SQL agent jobs will need to be run through an "upgrader" script of some sort, SSRS will need to be updated, SSMS will need to keep check the agent version before presenting the UI to the end user (to ensure it doesn't present features that shouldn't exist or miss features that should).
I think if they are going to go this route, it would be better to take the extended events route and build up a brand new service for this that can be run in parallel with the old service for multiple versions going forward (profiler and exctended events is what I am thinking here). This will ensure no loss of current functionality or skillsets and will protect systems during an upgrade to the new Agent 2.0. Imagine you have 1000 report subscriptions on your SSRS server and you upgrade your database and ALL subscriptions start failing and you need to manually script out an update to it? Or your backup jobs fail because you didn't indicate if step 2 can be run in parallel with step 1?
Another advantage of having a different service is you have time to plan and stage your upgrade to the new service without breaking existing functionality.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!