To be able to create blog pages where you could publish blog posts, on which people could comment on, and which would have an rss feeds aswell. This way people who need a news or updates etc. page for their wiki wouldn't need to install a separate cms, like WordPress, alongside their wiki.

I would like to have a button to show the article in a full screen view with the sidebars collapsed. This would make it easier to view the articles on a tablet, see pictures side by side in a table, and more.

Currently when moving or renaming a page, all existing links point to the old page. The correct behaviour would be to update all links to the new page, either optional or explicit.

When an image is pasted into the visual editor it is embedded on the page. I would like to be able to convert an embedded object into an asset and select the folder and name of the asset and similarly if an asset is inserted be able to convert it to an embedded image on the page.

If a draw.io file is going to be used in multiple locations in the wiki, I would like to be able to create a draw.io file as an asset instead of embedded element in the wiki page, and be able to insert it accordingly.

The rendered draw.io file only shows the first page. It would be good to be able to access all pages of the embedded draw.io file.

To be able to open images that are inserted on the page in a popup/modal window or in a FancyBox/Lightbox. Also, to have varius types of galleries, sliders and slideshows for the images.

When a user created or edited a page, it wont publish right away, rather have a admin or higher lever user to approve the modification, then publish.

Save current state of the buffer when editing a page, so in case the page is closed or the browser crashes, the work is not lost. This would work better with a warning when the page has been changed since the time the draft was saved.

Let's assume we have two people editing the same document. If Person A adds / changes a few lines in section 1 and Person B adds / changes a few lines in section 3 - that isn't a merge conflict that requires manual resolving. Both changes can simply be combined into one. If on the other hand Person A edits lines in section 1 and Person B edits the same lines in section 1 - that is a conflict that needs manual resolving. Someone needs to decide which parts of either edit should go into the final change. It would be great if the first type of conflict could be merged automatically, because the diff-view is really difficult to read and use. That would also be what people are used to from GitHub / GitLab or other version control platforms.