In my reply I focused on why we need a bundled, sandboxed packaging format in the first place, since many people are sceptical just about that. So you're right in that I didn't go into any of the differences.
Snaps solve a bunch of problems that are out of scope of Flatpaks, such as CLI apps and the packaging of kernels and other hardware-level pieces. This allows for an entirely snap-based system that is immutable and atomically updated, which is essential for IoT devices to be reliable.
If you look at the history of snaps, they are an evolution of click packaging, which were created for the Ubuntu phone that is no more. But the history goes back further than that - back to Ubuntu's App Review Board and (deb based) third party app packaging system, which failed for exactly the reason that deb is an unsuitable packaging format for third party apps.
If you look at the history of Flatpaks, you'll find that their initial release was at a similar time to snaps. But given that they don't solve a bunch of problems that snaps do, what was/is Canonical supposed to do? Ditch snaps entirely and drop their IoT support? Integrate IoT support into Flatpaks? Do Flatpak upstream even want that? Look at the history of Canonical wanting to ehnance GNOME, and the history of how Unity began, to see how that doesn't seem like it would be a practical way of delivering functionality to users in a reasonable period of time.
Consider that it is Ubuntu that is at the centre of this third party app packaging problem. It's Ubuntu that everybody targets first with their third party debs. For the same underlying reason, it's Ubuntu that gets more user support requests because of bad third party debs than every other distribution. It makes sense that Ubuntu developers are best placed to understand the problem and develop a solution.
So yes, we've ended up with two parallel contenders. But I don't think it's reasonable for Canonical to have done anything differently in regard to Flatpak. It appeared at the same time while Canonical had already been working away at the problem for years, doesn't solve or even try to solve all the problems that snaps are designed to solve, and those problems appear to be out of the scope of Flatpak anyway. As much as critics frame them as like-for-like options that Canonical could just decide to switch over, they simply aren't and thus "simply switching" doesn't even make sense.
As for "another one already exists", that statement could just as well apply the other way round: look at the timelines!
Snaps solve a bunch of problems that are out of scope of Flatpaks, such as CLI apps and the packaging of kernels and other hardware-level pieces. This allows for an entirely snap-based system that is immutable and atomically updated, which is essential for IoT devices to be reliable.
If you look at the history of snaps, they are an evolution of click packaging, which were created for the Ubuntu phone that is no more. But the history goes back further than that - back to Ubuntu's App Review Board and (deb based) third party app packaging system, which failed for exactly the reason that deb is an unsuitable packaging format for third party apps.
If you look at the history of Flatpaks, you'll find that their initial release was at a similar time to snaps. But given that they don't solve a bunch of problems that snaps do, what was/is Canonical supposed to do? Ditch snaps entirely and drop their IoT support? Integrate IoT support into Flatpaks? Do Flatpak upstream even want that? Look at the history of Canonical wanting to ehnance GNOME, and the history of how Unity began, to see how that doesn't seem like it would be a practical way of delivering functionality to users in a reasonable period of time.
Consider that it is Ubuntu that is at the centre of this third party app packaging problem. It's Ubuntu that everybody targets first with their third party debs. For the same underlying reason, it's Ubuntu that gets more user support requests because of bad third party debs than every other distribution. It makes sense that Ubuntu developers are best placed to understand the problem and develop a solution.
So yes, we've ended up with two parallel contenders. But I don't think it's reasonable for Canonical to have done anything differently in regard to Flatpak. It appeared at the same time while Canonical had already been working away at the problem for years, doesn't solve or even try to solve all the problems that snaps are designed to solve, and those problems appear to be out of the scope of Flatpak anyway. As much as critics frame them as like-for-like options that Canonical could just decide to switch over, they simply aren't and thus "simply switching" doesn't even make sense.
As for "another one already exists", that statement could just as well apply the other way round: look at the timelines!