In T410708#11395143, @Aklapper wrote:

The button that already exists at the very bottom of the edit field should also exist at the top of the edit field (see image)

I expect a good number of questions if there is any difference in using any of the buttons, and why the heck there are two of them.

If you think two buttons would confuse people, make it an option where the button appears. The main target for me is that the button does not appear on the other side of the list that get's longer and longer with every item added.

With every item you add, the button moves further and further away from the user thus making it more annoying to save your changes

Following the logic in this ticket, if the list of items gets even longer, there should be a third button in the middle?

Sorry, but the "logic" you read into my request is not represented in the text and (IMO) is not logical at all.
I suggest carefully reading the text again as if you do, the target of it is very clear: "button 'moves away' from the user", "With every item you add, the button moves further and further away", "user can make a change and save it right away exactly where their mouse cursor is", "They don't need to move the mouse cursor to the other side of the edit field or scroll through a long list.", "this would result in less mouse movement and a more ergonomic edit of structured data"

The suggestion clearly is to have a button at the point of minimal distance from where your cursor already is resulting in less unnecessary mouse movement, more ergonomic work flow and reduced time while editing.

The solution is not to add more duplicate buttons.
Maybe the solution is to always display one button no matter where the list has been scrolled to, but that's not what this ticket proposes, thus declining.

Wrong again: The main focus is a more ergonomic workflow.
I don't really care how this is done. As the main focus is important and not the way how it is done, I have reopened the ticket with an adapted text (This makes much more sense to me than creating >1000 tickets that get declined because they don't fancy the taste of the person who is closing the tickets).

I now realized this is not really a counterpart of T142082.

There are multiple problems inside:

• The MediaInfo editing interface is using a "semi-section" edit mode, which means there are no button to save single statement and in one single editing interface we can edit all statements of one property (but not multiple properties).
• The MediaInfo editing interface is not really as "compat" as Wikibase one so just a few qualifiers will make one "semi-section" (all statements with one property) too long and one "semi-section" only have one save button.

So I think the better solution is to make the "publish changes" sticky, so user can save change wherever you are browsing (as long as in this "semi-section").