@Umherirrender I don't understand your request fully. Can it be that for a casual user it is impossible to
retrace your issue!?
Comparable to T28312 (normally there is no separate summary and sectiontitle)

What I understand is, if in the text is an headline, then made it to the summary section.
I have this functionality implemented here:
https://de.wikipedia.org/wiki/Benutzer:Perhelion/sectionSummary
https://de.wikipedia.org/wiki/Benutzer:Perhelion/sectionSummary.js

Maybe this is owing to the hack of the German Common.js, which does (enforces a section edit to all new edits):

/**
 * Fügt eine Betreffzeile auf leeren Artikel-Diskussionsseiten ein
 */
if( mw.config.get( 'wgNamespaceNumber' ) === 0 || mw.config.get( 'wgNamespaceNumber' ) === 1 ) {
 $(function() {
  $( '#ca-talk.new a' ).attr( 'href', function( index, attr ) {
   return attr + '&section=new';
  });
 });
}

I do propose WONTFIX, because a section edit must always have a new section (this is the simple and main definition of it), this is a feature not an obstacle what we need to change. I think what @Umherirrender want is rather similar to a reverse of the German code above!?

This bug is about a compare of two functions. The one is the action=edit&section=new of index.php (gui part) and the other is action=edit of api.php (api part).

The gui part with action=edit&section=new gives two input fields, one for the summary/new header and one for the text. When the summary input field is empty and the user press the save button, the text of the text input field is now saved at the end of the page without a new header and without a edit summary.

The api part has the same behaviour, but I want create a edit without a new header and with a edit summary (for example the header is coming from a substituted template, like a welcome template). To get this work a possible way is to provide a empty sectiontitle= in the api request to explicit say that the summary= should not be used as sectiontitle=

It has nothing to do with javascript on dewiki which overrides links, it does not change forms or requests. The javascript also only doing something for non-exist talk pages. The requested behaviour here is also for existing pages.

Change 535333 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/core@master] Don't use the summary for the section header of a new section

https://gerrit.wikimedia.org/r/535333

Change 535333 abandoned by DannyS712:
Don't use the summary for the section header of a new section

https://gerrit.wikimedia.org/r/535333

Should be easier to do once T157658: Factor out a backend from EditPage merges

I think this issue is mostly caused by type confusion. Several places in EditPage do $this->sectiontitle !== '', but for setting the property it uses $this->sectiontitle = $request->getText( 'wpSectionTitle' );, so empty string and unset parameter are equivalent. I believe that when setting the title it should use null as default, and use that to determine if a sectiontitle was specified. This way:

• If sectiontitle is null, use the summary as section title
• If sectiontitle is the empty string, suppress the section title entirely

Change 805239 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] Add edit API tests for combining 'summary' and 'sectiontitle'

https://gerrit.wikimedia.org/r/805239

Change 805240 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/core@master] Fix edit API using summary as section title incorrectly

https://gerrit.wikimedia.org/r/805240

Change 805239 merged by jenkins-bot:

[mediawiki/core@master] Add edit API tests for combining 'summary' and 'sectiontitle'

https://gerrit.wikimedia.org/r/805239

Change 805240 merged by jenkins-bot:

[mediawiki/core@master] Fix edit API using summary as section title incorrectly

https://gerrit.wikimedia.org/r/805240

Caused T311489