We want to make the move to the new pat-contentbrowser as distraction free as possible, but these options will not be available there anymore.
Right now we are working on registering the svelte components with @plone/registry. These can be customized when you register your own component in your addon like described here @plone/registry - npm (see "Component Registry")
As a POC I started with the SelectedItem component to make it possible to override this to change the look of the selected items list.
I am not using any of these options, but have a question based on a use-case of pat-relateditems I am unsure pat-contentbrowser addresses: when you do not want to browse, you only want to search. Is the assumption that such cases should be using a different pattern/widget?
On sites with very-many items, or many items in few folders, sometimes browsing gets to be a noisy depth-first human traversal, and search alone can be the preferred means of finding internal links in the TinyMCE link modal.
I maintain a system that uses CSS and config to hide some pat-relateditems (e.g. toolbar and ability to browse to search context) inside the linkModal, with search (custom vocabulary and custom search adapter) based on everything-in-the-navroot and results relevance-ranked on weighted fields. For this system, the stated requirement is that the link modal's internal link functionality be search-only (I expect we can maintain an internal fork of plone.staticresources to ensure this).
We talked about the "search mode" in pat-relateditems and if we should implement it at all in pat-contentbrowser because we think that pat-select2 (implemented in Select2Widet and AjaxSelectWidet in p.a.z3cform) might be the better solution for this.
But ... in order to provide a mostly feature complete replacement for relateditems I implemented the search mode in contentbrowser too so that only one column is shown. The vocabularyUrl option is exactly the same as in relateditems widget so there should be no breaking changes.