1) When clicking / taping on another "stream" (or how is "unread" / "starred" / "newest" / etc. called?) in menu (let's say I'm in "unread" and I click "starred") - then last item from old "stream" (in my case "unread") appears focused and open in "starred", even when it is not starred.

Thanks for the feedback. When I implemented the new URL navigation, I was not sure what should the behaviour here should be and I went back and forth several times on it. Thinking about it more, I agree that it makes more sense to throw away the selected article as the user clearly finished reading when they switch away from the article.

This also happens when I'm in "unread" and push "r" (reload) - last focused item stays under cursor and is focused / open, even when it is already read. It is also a question, what should happen, when I'm on last item in "unread" and push "r" - in my opinion empty list should appear.

Yeah, this is less clear cut – if we think about the article like an anchor (it is likewise in URL), reloading the page as is would preserve the anchor. But I can see that the main use case for r key is to clean the unread view of read articles so it makes sense for it to throw the active article away too.

2) When I click on "stream" in menu, which I'm actually in (let's say I'm in "unread" and I click / tap "unread") - in 2.18 current stream was refreshed, and I was staying "unfocused" on the stream. Now nothing happens. I was used to refresh stream this way mostly on mobile phone, because hitting "r" is a bit complicated without keyboard. Later I used to refresh by "refresh" Firefox button, but I still think refreshing by "reclicking" current stream name was not a bad idea.

I fully agree, I used to do the same . Unfortunately, it is a bit complicated to do with the new navigation library since it is URL-driven but I will see what I can do about it.

3) "Next" button in mobile version is brokem (again) and does not load next item, but closes actual item and returns to a list. "Next" button is not in mobile interface, I'm using "user.css" to show it. I think it should be visible by default, but I understand this is my own "personal" wish, but anyway - how do you use selfoss on mobile phone? "Next" button is the only action I want to push for maybe 50% of my content... But if user.css will be working, I'm fine with "unhiding" it.

I do not really use mobile phone much and when I do, I read just specific articles rather than clicking “Next”. But I do see the utility.

Looking at the CSS, it is only shown on tablet-size screens. No idea why, perhaps it would not fit on a smaller screen of smartphone? But it definitely should work, and it does seem to in some cases. Though, there seems to be something weird going on.

4) When speaking about user.css... I have .entry-toolbar .entry-next and .entry-toolbar .entry-newwindow to display: block. Souldn't be handy to - ehm - have ... "entry-newwindow" always visible on mobile? Just asking. I can imagine some country / area, where there is actually some content in css, but ... everywhere else in universe you have only some perex or maybe only headline and you have to open the article in new window (new tab actually) to show you actual content (and a lot of adds). I think this A++ function, but - I understand - maybe I'm just different person.

With FullTextRss/Graby content extraction, you have full content and unless something breaks, no need to visit the article on the website. But these kinds of questions are definitely something we should evaluate. Selfoss ought to provide a good user experience by default (with the option to customize for people with different preferences).

5) Now - when we are here - the best. Combination of all the previous annoyments. […] When I'm on mobile in "unread" and I'm actually on last "unread" item, so everything is read now. I want to refresh the stream, so I hit "three dots" button in Firefox, refresh.

Yeah, we now put the ID of the current active article into URL, which allows users to somewhat continue where they left of. The down side is that when you want to dismiss it, reloading the page using the web browser will not do it since we cannot reliably distinguish between visiting a URL with ID and reloading (correct me if I am wrong). Hopefully, fixing 1) and 2) will be good enough.

(Please don't take this as criticism, it's ment to be user feedback. Selfoss is super cool, kudoz to all devs, and I'm on it until end of Google Reader...)

I am very thankful for any feedback, especially about features I myself do not use, which allows me to have better insight into users, which will hopefully result in better user experience.

The user interface code has been almost completely rewritten since 2.18 so there are definitely more bugs and regressions hiding so I definitely appreciate any reports.

I have opened https://github.com/fossar/selfoss/pull/1286 for 1), https://github.com/fossar/selfoss/issues/1287 for 2), and https://github.com/fossar/selfoss/issues/1288 for 3).