Aahh ok, so you’re essentially talking about a dynamic result page which might have different appearances based on the search term.
So in general I’d, without knowing more details, would say you’re good with one Page Object. Whether there are 3 or 4 buttons is merely a state of your PO. Unless that is that each state has utterly different behavior. In that case I’d think they are no longer representing the same component.
E.g imagine you’d have a toggle button. If its active its State A, if its inactive its State B, but still the button is part of the same PO and does pretty much the same thing -> Switch from one to another state.
Now as far as it goes for the Screenshot, Selocity can only capture the visible part, thus your generated PageObject screenshot will most likely only show 3 or 4 buttons, except you have a condition that shows all 7 of them. The screenshot though is just a reminder for the user (what part of the page am I working with) and has no other immediate effect.
Moreover whats interesting though, you’d most likely have elements in your PO defined for those individual buttons. In that case I’d propose to add selectors for all the 7 there.
A very important thing, that can’t be stressed too often, is that the term Page Object is a bit misleading as it comes from a time where UIs have been pretty simple, so a PO per Page was sufficient. Nowadays you should try to think more about a Component Object. Speaking a part of the page (or perhaps even reused in multiple places) is your Po. That might also reduce the overhead of your ResultPo.
So if you feel like the complexity of your ResultPo starts to grow (too many states encompassed), perhaps try to break it down even further. E.g the list of results could be a ResultsListPo, whereas the mentioned buttons could be put into a ResultsActionsPo.
As a software developer a good practice is to follow the YAGNI model which essentially tells you to stop doing too many abstractions right away since … well you ain’t gonna need it most likely
Another important practice though is continuous refactoring. That means feeling brave enough to change existing code in order to reshape it for better re-usage. I think both of those could very well apply to your situation. Start small with a single Po for the results. If things get tiresome, start to slowly refactor into smaller POs, and if things go south due to vastly different state effects, introduce individual POs per state.