Nice catch! In my opinion, Edit Recovery should probably take precedence. Consider an editor who starts a proposal in the Community Wishlist Survey (which uses preloaded text). They work really hard on it, but before they can save, their browser crashes. That's a clear use-case for Edit Recovery.

The other question I guess is when the preloaded params change, as mentioned in #3 of the repro steps. This is a pretty unlikely scenario, and based on that alone I'd say Edit Recovery should still prevail. Following T342721, editors will always have a way to "undo" Edit Recovery anyway, in which case the (new) preloaded text should be restored. So from a usability standpoint, I don't see conflicting preloaded text as a huge problem given the user will have a means to control what they want.

I agree with @MusikAnimal I think, now I've used it for a few weeks. Edit Recovery should take precedence, as long as it's easy to discard the recovery data.

However, I think there might be some gadgets that load text into the form in a quasi-preload way, and their text might get clobbered with no way to get it back — I can't find any such gadgets now that I'm looking though! But the flow I'm thinking of is something like: a gadget could execute in the wikipage.editform hook, and set the contents of some form fields, but because gadgets happen after Edit Recovery has registered it's own handler for that hook, the gadget's text gets overwritten (which is how we want it to be).
Example gadget:

mw.hook( 'wikipage.editform' ).add( function ( $editForm ) {
	$editForm.find( '#wpTextbox1' ).textSelection( 'setContents', 'Lorem ipsum.' );
} );

Anyway, I think everything's fine as it is.

For my understanding, why can't preloaded text and edit recovery text be preserved?

For my understanding, why can't preloaded text and edit recovery text be preserved?

The issue is that the preload text can change, by changing the preloadparams that are passed (details about this). See the changed two parameters in the example URLs from above:

https://en.wikipedia.beta.wmflabs.org/wiki/New_Page_Preloaded_Params_Example?action=edit&preload=Param_Demo&preloadparams[]=first%20value&preloadparams[]=second%20value
https://en.wikipedia.beta.wmflabs.org/wiki/New_Page_Preloaded_Params_Example?action=edit&preload=Param_Demo&preloadparams[]=new%20first%20value&preloadparams[]=new%20second%20value)

This means that the text that's preloaded in the editing form is different for each of these URLs. So imagine you've opened the first link, started typing, and ER has saved what you've done — and then you open the second, expecting (perhaps) to see the different preload text but actually you get what you'd already started (because it's still the same page and so the ER data is recovered). Then, you want to discard what you've done, and you end up with the 2nd preload text rather than the first (which is expected, because that's the link you opened).

Thanks for the clarification. Here's what I'm thinking..

1. I have doubts that preloaded params will change very often.
2. I have even more doubts the preloaded params would impacts someone's edits

Therefore, we shouldn't worry about changes to preloaded params.

What do you think @Samwilson ?

Yes I think we can just store the first preloaded text. There could be some issues with, e.g. workflows that involve preloading sections (including their titles) with parameters that change, but I think we can revisit it if people report problems.