The real issue is not gtkmozembed but whether or not there exists a way to embed gecko into a GTK app anymore via some other method. If its still possible to embed gecko into GTK, we are good since the only thing we need to remain ABI compatible for users of microb/gecko is the dbus interface exposed by tablet-browser-daemon (for nokia maps it doesn't look like cloning the actual nokia-maps binary so it can talk to the browser engine in a different way would be a massive undertaking)

If there is no way to embed Gecko into a GTK app anymore then we could come up with a new browser engine/UI that replaced microb as the system web browser (with the same level of system integration as microb had) and kept only those bits that rtcom-messaging-api/maps actually need.

So to figure out where we go from here we need to answer the following questions:
1.Which non-browser packages on Fremantle use libraries that can be considered part of the "browser" (whether that be tablet-browser-*, browser-eal, browser-neteal or otherwise)
2.Is there still a way to embed the Gecko rendering engine into a GTK application that can be used on Fremantle? (via embedlite or otherwise)
and 3.If not, is there a way to embed Webkit into a GTK application that can be used on Fremantle?

Having regard to the answers to #2 and #3, would it be better to:
A.Use new-Gecko as a replacement for browserd
B.Use new-Gecko in a new browser UI (that replaced the system browser but not the engine used by rtcom-messaging-api/maps)
C.Use Webkit as a replacement for browserd
D.Use Webkit in a new browser UI (that replaced the system browser but not the engine used by rtcom-messaging-api/maps)
or E.Keep microb as the system browser but make a new browser (with either engine) that installed alongside microb (and didn't try to integrate with any system stuff)