Going over the past discussions, I can't find a point where it was thoroughly discussed how to address the issue of changing state without being able to change the resolution/videomode. setState seems simple enough, but in most cases when switching from windowed to fullscreen, you actually want to pick a different window size, with the only exception if you were already using a borderless "fullscreen" window.
Additionally, the reverse is also true, when you start with a fullscreen window at a fullscreen resolution and you switch to a floating window, you usually don't want the same resolution.

One proposal would be to add a second overload setState(sf::State, sf::VideoMode) or setState(sf::State, sf::Vector2i). Then you define default behavior when there's no size provided (e.g. use the existing window size / use the default fullscreen video mode). Question then is, what you do once adding sf::State::Minimized and sf::State::Maximized, because those don't really work with different window sizes.

Laurent's comment from way back indicates, that he imagined, that users then would just start out with a hidden window and set the properties before showing it. This solves the potential issue of the initial creation, but leaves the question of toggling unanswered.

Comments and discussion are appreciated 😉

I've created an alternative/extended API design as a separate PR: #3501

I would say leave them separate - even if we expect many use cases will want to set the size at the same time as the state I don't think it's worth the extra ambiguity just to save them an extra function call

Also consider mobile/console platforms where these states mean other things (e.g. on iOS fullscreen may be used to indicate ignoring the safe areas) which may also trigger a window resize from the OS so the extra size parameter would become even more ambiguous