Ctrl+Arrow-down is used to focus "tags". Ctrl+Shift+Arrow-down is used to select a paragraph. Maybe Ctrl+Alt+Arrow-down could be used.

With v2.1.1 we have Shift+Esc to minimize the main window while keeping an existing filter and we can deactivate "Minimize on Esc" using a menu option. What is actually left to a clean interface (imo) is an option to reset a tag and a search-text-filter in one step as here requested.

This would give us:

Esc                  reset all filters

You're absolutely right! I was so focused on my (ESC) workflow, that i did not realize i could actually use these two keys. I have now turned off "Minimize on Esc" and am curious how it will affect my workflow. Thanks Alex. Please close/decline this post.

With version 2.0 (?) the feature "Minimize on Esc" was introduced. When turning the feature off, it is possible to multi reset any filter, without exiting the main window. To complete the feature i suggest to introduce Shift+Esc to exit the main window, but keep any filter.

Imo the problem is, that CN uses the last window position and size as the default for other windows to open. So every window that will open up consecutively it will display as a very small window too, which is probably not what you intended. You might want to vote for this request individual size and position of editor window, which i have just created.

I don't like the idea of a central (cache) database. It can cause some trouble. For example, with Sqlserver i made the experience, that i could not access my databases, when one of the central databases had a problem, e.g. Master.mdf. The most i would like to have the relevance_value inside my db. I understand the shortcomings. How about the following summary: introduce CintaCache.db, a second db file that contains additional data to the main notes database. The file will contain a new table to store last access date and usage counter for each note. The both make up the relevance_value. (Remark: While writing this i realize the problem with this separated db approach: the relevance_value is needed in the main db to perform the order clause). There will be a cache db to every main db. Because the db contains data, that can not be recreated, the cache file needs to be part of the backup operation. Last access date, usage counter and relevance value need to be added to the xml export. The file will NOT be part of the syncing process, because of the dicussed issues. (Remark: After a client received a new main db from a sync server, how can its local cache db be updated, so that integrity between the main and the cache db can be achieved?). The whole matter of not being able to store the data in the main table, kills  my original idea. Imo the relevance_value can really make sorting more efficient. It is a pain it can not be achieved, because of the requirement, that it must not interfere with (dropbox) syncing. A feature i personally don't use. Would it really be so bad, if syncing would be caused by a read (which causes internal updates)? Maybe a true update happens a minute later, making this entire discussion meaningless.