Not sure what the threat model here is. Could you describe a full sequence of actions that would lead to a security problem? I am feeling like missing some context here.

The easiest scenario to understand is a vulnerable SMTP server. Now I'm aware that it is unlikely that people will implement SMTP servers in PHP, but I think it gets the idea across:

* Let's assume we have an authenticated (submission) SMTP server vulnerable to STARTTLS injection, a user and an attacker both have accounts on that server.
* The user tries to log into that server via STARTTLS.
* The attacker injects an additional EHLO command, an authentication with his own credentials and the start of an email to himself into the STARTTLS command.
* The server will interpret those and prepare sending an email.
* All further commands sent by the client/victim will be part of that email, including the authentication credentials.

A likely more relevant scenario for PHP may be spoofing of the content of an IMAP mailbox. Assume:
* A client with a STARTTLS injection vulnerability connects to an IMAP server with STARTTLS.
* The attacker injects commands into the (still unencrypted/unauthenticated) server answer to the STARTTLS command that already answers the upcoming commands the client will send to list the mailbox content. (This requries the attacker to know the exact chain of commands the client will send after STARTTLS, but with knowledge of the client software this is usually known information.)

The key issue in all of this is that content that is sent unencrypted and unauthenticated will be interpreted by one connection partner as if it was part of the encrypted/authenticated connection.

We have a scientific paper prepared on these attacks, I can share this with the PHP security team if you agree on keeping this confidential until we publish the paper.

Not sure I understand your scenario - are you assuming the attacker and the victim share the same TCP connection? 

Would be glad to see the paper (of course, won't disclose it, would be better to send the link to my email rather than post it here) but would like to also get an idea how the attack could be achieved practically.

Our research is now public: https://nostarttls.secvuln.info/

Maybe we can unrestrict this bug?

I am still not sure what threat model is assumed here. In my understanding, if the attacker and the victim share TCP connection and the attacker is able to inject arbitrary content into it, then all the data the victim is sending would be compromised in this scenario. However, I am not sure how it is possible that they would share the same connection?

That said, if somebody proposes the fix for this - that makes it clearer - I am ready to look at it.

The threat model is a classic man in the middle attacker, i.e. a person that can modify a TCP connection on the network.

The key issue is: With mechanisms like STARTTLS we have a transition between a plaintext protocol (where we expect that manipulation is possible) to a TLS-protected connection (where we don't expect manipulation to be possible).
The gist of this bug is that an attacker can modify the plaintext part of that protocol, but it will modify what the application thinks is the TLS-protected part.