This application lifecycle model is same across all platforms supported by Windows 10, only with a minor differences based on the device performance, memory, etc.

Application Lifetime - app can be in 1 of 3 states:

Application receives events when transitioning between states, Except: Suspended->NotRunning. This has not changed since Windows/Phone 8.1.

Extended Execution

Previously if user switched from app A to app B, app A was suspended with no way to continue running.
In Windows 10 it's possible to request Extended Execution from OS.
App must provide reason for extended execution: ExtendedExecutionReason.LocationTracking or SavingData or UnspecifiedThis is basically the replacement for background location tracking API in Windows Phone 8, that was missing in Windows Phone 8.1.

User can revoke the request for extended execution. Revoked events will have ~1 sec to clean up. Min time is guaranteed but opportunistic afterwards.

Opportunistic Background Tasks serve as a replacement for Windows Phone 8 that had no replacement in Windows/Phone 8.1 ResourceIntensiveTasks.

In-Proc Background Tasks

Originally background tasks were executed in separate process - with separate memory cap. In Windows 10 it's possible to define in-process background tasks - shares memory cap with the host process. This can be defined the Pacakge.appxmanifest.

Socket Trigger Tasks

Apps can have network connectivity and discoverability maintained while suspended or even terminated. Alternative to WNS triggered Tasks

How it works:

In foreground app process: Create/retrieve socket(s), Register background task to be woken up, Give socket to broker service as app is suspending, Take socket back from broker service at any time

On incoming network activity on brokered socket: Background task is triggered, Take socket back from broker service

Summary

Background processing is converged with Windows
There are lots of new things you can do
But resources are still limited