Unfortunately, your question is too broad. Please edit your question to include the switch model and configuration.

@RonMaupin It strikes me that this question does not require a switch model or configuration to answer. RFC 826 answers the question as written. Are you alluding to the possibility that replying devices might answer incorrectly, and the switch has to cover for them by "correcting" the ARP reply? That would certainly be switch-specific?

@CortAmmon Yes. How the switch is configured could determine if ARP is correctly handled or not. We cannot be sure any answer is correct without knowing for sure what the switch itself is doing. It could be fixing the problem. It should have the correct MAC address on the interface where the frames first enter the switch, but it may be configured in a way that will not allow it to send anything through that interface if it is not using the changed address. There are too many variables to provide a correct answer.

@RonMaupin But the specific questions at the end all deal with how the responder replies to the message, on the assumption the switch has already behaved in the way described in the second quoted code section. That response is defined in the RFC.

But we cannot answer the question, "Will this break anything?" Maybe it will, or maybe it will not, but we cannot answer that without more information. As it is explained in What if I disagree with the closure of a question? How can I reopen it?, "you should first try to edit the question to improve it as much as possible." That applies to anyone, not just the OP.

@RonMaupin Your behavior, and the behavior of those like you, make SE worthless for any question not trivially-answerable by drive-by commenters/flaggers. Within two hours of posting, this had two up-votes and one star; clearly they saw something in it you didn't.

I'm sorry you feel that way, but we cannot answer unanswerable questions. The way it works is that you ask a question and get an answer, but unanswerable questions cannot be answered, so they are put on hold, pending modification to make them answerable. That is the SE way. Speculation and guessing are off-topic here, and this is not a discussion site; it is meant to be an archive of questions and answers.

One thing I will note is that such a custom switch as you edited is off-topic here. Every SE site also has a What topics can I ask about here?, and ours says that a device must be "hardware that has a paid support option from the manufacturer (enterprise/provider class products, some small business class devices)."

Also, you should explain the masquerading. For example, NAPT not only changes the IP address on the packet, it modifies the transport-layer protocol to reflect the address change. Does your masquerading modify the ARP packet too? We do not know without more information.

@RonMaupin My question literally included this information. It specified in the first line that it was editing the Layer-2 information, and showed in the example that only the Layer-2 information was modified. The question was, as already stated, whether this would break things.

@RonMaupin The question was not about a switch, it was about the effect of a modified on an ARP packet. Without mentioning the switch - custom-made or not - as context, the response from people like you would have been "what switch does this" or "why don't you do this other thing instead," neither of which are useful to the question. I've been down that road before, so I attempted to provide context.