Motion seconded on the tagging idea. Really, it's pretty easy to re-conceive tab groups as follows: * The backend is the existing bookmarks storage. This alr

Motion seconded on the tagging idea. Really, it's pretty easy to re-conceive tab groups as follows: * The backend is the existing bookmarks storage. This already supports both hierarchical organization and tagging. * The API for accessing the backend is effectively a search that defines a writable view into bookmark storage. E.g. "folder X", "tag Y", etc. "A small matter of UX" required to work out sensible behavior in the event non-writable searches are allowed (e.g. "all bookmarks that are hits for word 'cake'"). Likewise, some additional per-view metadata might be required to maintain the user's tab ordering for views without an ad-hoc order such as tag-driven searches. Perhaps these cases could be accommodated via the addition of "smart folders" to the bookmark store, which encapsulate these searches, provide a place to stick search-specific metadata, subfolders with ad-hoc contents (e.g. user-opened tabs in that context), and so on. * The window's tab list management would transparently read/write tabs into the view associated with that window. * Window tab display should be screamingly fast. Got 100 tabs in that search? That window had better appear instantly. Honestly, that last shouldn't be very hard. (Warning: famous last words.) I haven't looked into the FF code for this (and I'm sadly unfamiliar with FF's codebase), but what are now standard list-view optimization techniques[1] from mobile platforms should make this a cakewalk. Anything needed for display should be stored in the bookmarks and/or cached, and there's minimal object allocation involved. [1] E.g. there only exist a number of view objects (say, visible tabs) equal to what can be displayed on-screen plus one or two. These are recycled as needed during any view movement (scrolling) or data change operations. Hark, I hear an excuse to learn Rust and go check out Servo...!