Packagekit has no such feature. It's unclear if it should even.

I've been digging through gnome-software and while it has EOL facilities I am not convinced they are actually functional.

gs-updates-page.c is the UI code for this, it refines a special "system" app and then shows/hides the elements depending on the refinement result.

	/* show or hide the end of life notification */
	app = gs_plugin_loader_get_system_app (plugin_loader);
[...]
	if (gs_app_get_state (app) != AS_APP_STATE_UNAVAILABLE) {
		gtk_widget_set_visible (self->box_end_of_life, FALSE);
		return;
	}
[...]
	gtk_widget_set_visible (self->box_end_of_life, TRUE);

From what I can tell the "system" apps is generated by the os-release plugin (gs-plugin-os-release.c) but that hardcodes the state to AS_APP_STATE_INSTALLED and I cannot find any point where that would get mutated. The gnome-software commit pertaining to this is also excitingly useless https://github.com/GNOME/gnome-software/commit/34a112c38d8f79fe2c8d699a340c84259f5e89f7

The way I see it this won't be an easy fix and likely not factor into bionic at all.
Needs discussing with hughsie and @apol. The way I see it since packagekit offers the upgrade controls it should also offer EOL data. If that is undesirably for whatever reason I suppose the best way to deal with this is a special plugin architecture in discover where distros can feed it EOL information.

(FTR: I've also noticed that appstream-glib has an os-upgrade 'kind' entity. I can't find any mention in libappstream proper though, may be worth checking with Matthias Klump what the deal is with that. Supposedly all releases could be described as appstream components and then marked EOL there as necessary?)

If we need to have a "neon upgrade" ad-hoc component already to trigger the updater UX, maybe it would make sense to include it there too?

For now maybe. I mean for neon EOL == upgrade because there is zero maintenance once the new version is out, just like there's zero maintenance for old Plasma releases on neon.

This extends beyond neon though. All distro releases eventually go EOL at a random (not predetermined) point in time (i.e. that may not even be related to upgrade paths being available).

Take opensuse for example. Leap 42 is the previous major release. From Leap 42 you can upgrade to Leap 15 since May or something. Meanwhile Leap 42 is currently planned to go EOL in June 2019 which may get pushed back if they fancy extending the support time.

So, there is a need to show a "Yo, wanna upgrade to Leap 15?" indicator somewhere with the ability of then somehow initiating that upgrade. For this we kinda have facilities in packagekit, debian systems architecturally just have challenges using the existing facilities.

As an upgrade on that is the need to show a "Yo, Leap 15 has reached EOL and isn't getting support anymore. upgrade now to Leap 42 or black hats will watch you through your webcam!" indication. Which is a bit of an upgrade in severity of the "wanna upgrade" message. For this we have no existing facilities in any piece of middleware. But we should!

I was thinking maybe @mak or @lbeltrame have any ideas.

In openSUSE the lifecycle data is part of /etc/product.d/openSUSE.product (openSUSE-release package) which receives updates through the regular channel.
The zypp PK backend reads those files and using "get-distro-upgrades" a list of available update targets can be acquired:
https://github.com/hughsie/PackageKit/blob/576cfb3d2568e88e01d823bef98c3981ad9d54f1/backends/zypp/pk-backend-zypp.cpp#L2205

I suppose it's possible to show the name and summary of the upgrade possibility to the user once it's available and include the EOL note in the summary.

Discover does support PK distro-upgrades support somewhat. apt and alpm backends don't support it, feedback would be welcome.

quick fix while we wait in distro-release-notifier
https://phabricator.kde.org/T9789

File bugs with PackageKit and maybe AppStream to support this

@jriddell This was actually planned for AppStream for a while - we are currently reviewing a spec addition for a new operating-system component. Let's see with what we end up implementation-wise. => https://github.com/ximion/appstream/commit/b4e40f562204e12f866b48a3c04da8b3483bdbf5