.NET platform is currently undergoing a lot of changes, probably biggest one for web developers since .NET 1.1. To understand what are bits and pieces people have to dig through presentations, msdn blogs , announcements and conference videos, because as usual MS PR department is too busy promoting something else I guess (not Windows Phone, that's for sure also). If there were no Scott Hanselman, Scott Hunter and Damien Edwards I would probably be still scratching my head;)

At the time of writing this text, this is what we as community know:

.NET 4.5, 4.5.3, .NET 4.6, .NET 5, .NET …

If you create a new project in Visual Studio 2015, you'll see one new item in the frameworks list, and that's 4.5.3. Also named 4.6 Preview on some sources. It comes in two variations: Full CLR 4.5.3 and Core 5 (switch between in command line with KVM, or just right click to your project in VS, and open properties). 

.NET 5 or "Core .NET" is a subset of 4.5.3, cross-platform (meaning you can call Microsoft directly if your app has problems on Linux, and works on Windows for example. And you have support contract of course) open sourced and under .NET Foundation, created for new ASP.NET 5 runtime. Simply put: 5 < 4.5.3

Created on foundation of fallen Silverlight, since it had CLR runtime for running .NET cross platform (I heard this info on some podcast, forgot where and when. Please share some light in comments on this if you know, maybe I'm completely wrong!). Pragmatic and understandable approach, if I may add.

Relies on famous OWIN spec, a delegate described simply:
var middleware = Func<Dictionary<string, object>, Task>

bent by Microsoft a little bit to suit the needs of a platform and app development (probably still ongoing conversation about definition of iAppBuilder, IApplicationBuilder, Startup class, what should be in there and what not; where the line between vendors implementation and what is part of a spec), but everything built on top of .NET 5 / ASP.NET 5 can rely just on that middleware delegate, no more ties to OS. Whole framework has around 10MB, so as you can imagine, lot of things are missing, like WCF, WebForms, WPF, …

Just remember, if you’re building something that has to be cross-platform, don’t depend on IApplicationBuilder, but just on OWIN delegate, and add registration to execution pipeline (appBuilder.UseXY()) as an extension method.

ASP.NET vNext

Currently, on .NET Core 5 (ASP.NET 5, or ASP.NET vNext or just vNext) you can run: MVC 6, WebAPI2, SignalR, WebPages, NancyFx, and the whole thing (Core 5, Kestrel, Helios, Configuration, projectless projects, DI, Roslyn on-the-fly compilation…) is named ASP.NET vNext. It's still under development, but even though surface API stabilized in last few months, it's not ready for production.

MVC 6 project template includes Entity Framework 7, which is in alfa stage (Jan 2015) , and like Full .NET Vs Core .NET, it contains only subset of features from EF 6. Looks like a step back but it's really a complete rewrite of almost 10 years old ORM which was just too heavy and complicated to maintain and expand.

Also, Core 5 doesn't run WebForms, and i think it never will (reminder: change this sentence if I was wrong).

So long story short: .NET 5 is bin-deployable usb stick-portable subset of 4.5.3. It's cross platform and can run only new MVC 6. For everything else, use 4.5.3.

Entity Framework 7

Entity Framework 7 in first version will not support bunch of "advanced" features from v6, so think about it as Light EF MicroORM vNext v1. Looks like EF, smells like EF, but doesn't compute like EF.
Works on 4.5.1+, where EF 6 doesn't work of Core 5. I would use it just if I have a good case for it, for example I want to run my app on the WinPhone. When it’s finished, it will work with NoSQL document storage (Azure Table Storage will be one of the first supported stores), Sqlite and PostgreSql (awesome db!), other providers are expected after the release. Final release is expected after Core 5, so don’t really know what will be bundled in MVC 6 RTM template; EF6 doesn’t work on vNext, and E7 will not be RTM ready till then.

KRE

Windows always automagically knew how to spin up CLR runtime when we double clicked on .NET created .EXE or requested an ASP.NET app through IIS. On Linux we have to write “mono …”. And now with cross-platform Core 5, we have KRE runtime loader (K Runtime Environment) to do that. It's also used as an application host instead of good ol' rusty System.Web, and for running Roslyn to compile on-demand or on-the-fly.

KVM

K Version Manager, used to switch CRL runtime, or KRE. Useful commands to upgrade or install KRE can be found here https://github.com/aspnet/Home/wiki/Version-Manager. In the future we will have several versions of CLR runtime, and we can just switch between them, or upgrade any with simple command. I’ve seen this in Python world, looks and works great there … 

KPM

K Package Manager. Like Nuget, just works (finally) without Visual Studio (Nuget prior to v3 relied heavily on Visual Studio for adding references to a project and bunch of other stuff, for example).

There are two important commands to remember:

KPM restore - restores all the packages defined in project.json

KPM pack - pack your app in self-contained deployable directory

Katana

When OWIN was drafted and reached v1, Microsoft needed an "adapter" to run OWIN-based apps on top of ASP.NET 4.5, meaning System.Web. And that's Katana, created as temporary solution until we get final Core 5. Contains hosts, servers and middlewares so we can run OWIN apps on IIS, self-hosted with HttpListener.

Don't quite know what will happen with it, but it seems we'll need those set of libs if we want to run OWIN apps on full CLR 4.5.*

Helios

For every request IIS calls into System.Web, which heavy architecture optimized for big statefull web apps (that's how they envisioned web should work in 2000.) is just not optimized for many small request and todays usage scenario (REST, microservices, etc). OWIN is free of System.Web, so new server for hosting ASP.NET on IIS could be built, and that's Helios. It uses around 3kb per request, compared to 30kb of System.Web, enables a lot more concurrent connections per server. Think of Node.JS performance, or even better.

Nuget package is Microsoft.AspNet.Loader.IIS, and runs on IIS and IIS Express

Kestrel

Like there's a Helios for IIS, to server request on Linux there's Kestrel (works on Windows also). Built on top of libuv, cross-platforms asychronous I/O, battle tested offers and with great performance. Libuv uses single threaded event loop to receive incoming request, which are then handled over to .NET thread pool.

It’s important to use it properly and not just expose Kestrel HTTP endpoint to public, but rather keep it behind some "real" HTTP server, like Nginx.

Nuget is Microsoft.AspNet.Server.Kestrel.

Hope I shed some light on current platform state, since everything is kind a moving targer right now, or needs an overview. In few months things will be much clearer, and until then…

One more nice and confusing picture with lot of geeky information that explains everything and nothing in the same time: