I thought about not writing anything yet... but then the queryable topic was just to important not to speak out about now rather than later.

I'd definitely go for Option 2.  This has several benefits:

1. queryable - What's the point of making structure, if we cannot query the structures en masse?  There's no point in making structures then in the first place.  Are we saying that we don't want to include abstract content in the database of knowledge?  It doesn't have to be queryable via SPARQL, but abstract content needs to be queryable.  Not being able to query abstract content will be a complete non-starter for me and likely many other contributors later on. 

2. RDF tool extensions later on can be developed to understand the abstract content structures; so I'm not worried that it won't be queryable later on given some time for tooling to develop.

3. The UX is something that will need to "break the mold" certainly, but it needs to be and probably a good thing to start doing and working forward on toward a design system around context control where historically that was namespaces, but that segments the relationships of items too much and makes tooling, metadata, and many other things much harder.  One possible way that works across all browsers is <iframe>.  Simple, ancient tech yeah, but it also has the same effect as the tab option since it can encapsulate even an entirely different app (Vue3?) within the same viewing window of browsers.  The downside is that the HTML page indeed grows larger in size (<iframe>'s are embedded in existing pages), but showing and hiding <iframe>'s is trivial and can be a preference.

In the end, we can see that through all the options you listed and maybe others, we are looking for a good hard relationship between an Item and its abstract contents.  Some of the options make this explicit, and others implicit.  I'd go for explicit with option 2 by having the new datatype, that automatically brings the ability to add new metadata when the future needs arise (like we've done before for certain datatypes), which is something that will be needed for context, such as your examples of "history", "etymology", "wikivoyage", etc.