Is it necessary to patch ACME standard to differentiate new-order with replace-order?

You are free to diverge from the ACME RFC to implement new endpoints and try to gain acceptance these concepts but I strongly doubt there will ever be a "reissue" or "replace-order" endpoint adopted by the IETF working group into the ACME standard or as an new standard to extend 8555.

As many have stated before, RFCs are standards that represent what the industry has adopted, not what the industry should support:

You can certainly develop your own extension to ACME to implement this and work with other commercial CAs to advocate it being adopted by IETF, but I do not believe the adoption effort will be fruitful.

The behavior you are requesting sounds very specific to your own needs, and will likely vary across commercial CAs. I also believe it would be "Dead On Arrival" with the IETF and many other commercial CAs, because the concept conflates the concepts of an ACME Order with a CA's customer order.

The RFC defines an ACME Order as an ephemeral request (a requested certificate, which may or may not be fulfilled), which is wholly different than a CA's own concept of an Order -- which typically means a fulfilled Certificate that may have taken two or more ACME Orders to fulfill.

(RFC 8555 - Automatic Certificate Management Environment (ACME)):

An ACME order object represents a client's request for a certificate
and is used to track the progress of that order through to issuance.
Thus, the object contains information about the requested
certificate, the authorizations that the server requires the client
to complete, and any certificates that have resulted from this order.

There is no need to support this flow. Commercial and Free CAs are successfully able to handle this sort of account management and bookkeeping through existing means. The features you suggest would complicate the operations of existing Certificate Authorities and provide no real benefits. These types of actions are general bookkeeping and accounting measures, and already successfully handled by commercial CAs within the spec with no divergences needed.

Supporting this in clients would also be incredibly complicated, as you are also trying to introduce what Certbot calls "certificate lineage" into the ACME process. IMHO, adopting such a standard would ultimately create many compatibility issues as many clients and CAs would have no need or desire to implement it.

I suggest you read the full topic from the quote I shared above about RFCs. This sort of custom behavior, and potential extensions to support it, is certain to be best handled within the existing endpoints and flows by submitting the additional information as part of the new-order request.

Edit: As others have noted, the ARI extension - which LetsEncrypt implements and other CAs are assured to follow - introduces a replaces field to new-order -- which is essentially what I suggested in my last paragraph.