this is not how the mail function works

simply speaking: it doesn’t care if an address does not exists. or if your settings are incorrect .
all it cares about is that there is no *fundamental* syntax error.

whether an smpt sever or email address actually exists and whether the settings for it are correct it doesn’t know anything about

furthermore, of the 3 mail options you have in the plugin (mail, wp_mail, phpmailer) only the last one would let you set smtp settings (unless you are using a 3rd party plugin to override things, but that’s a different story altogether)

on a more practical level:
if that particular part of code you are referring to returns “FAILED”, the customer on the frontend would end up with a big error message along the lines of

“Apologies. There was an error receiving your order. Please try again.”

so it does not really make sense to display this order anywhere as the customer will not expect (unless he can’t read) this order to be received/fulfilled, so the restaurant should not process the order anyway.

as mentioned, this will only ever happen if your mail function has been disabled for example or there’s something fundamentally wrong elsewhere

forgive me, but what you are requesting does not make much sense to me, but feel free to expand if i missed something

ignoring for a second here the obvious necessity to make sure that your email setup is correct:

a) > they claimed they saw no error messages
always an outside possibility of course , but i don’t think very likely (unless you are running a very old version of the plugin)..that’s just by the by …(though one of the next versions will have that writing highlighted a bit better)

b)>I always make this little change…
surely, this is the wrong approach.
forcing a db entry to be completed as opposed to failed (when it did fail) is NOT what you should be doing.
what you *should* be doing, is DISPLAY any failed transaction so you know that and why they failed.
what you *are* doing is telling the db that everything is fine, when it was not

in any event, i can probably add an option in the backend somewhere – either in the order history itself or under wppizza->settings->miscellaneous – to also display failed transactions (with the info why they have failed)

> based on my experiences with a very old version…

i’ll let you off then 🙂

>the option to show failed orders with reasons would be a great new feature

i only somewhat agree here. having said that, it should not be too much of a problem to add this.
will probably do this in the next version. however that’s still a bit away ( a couple of weeks minimum and there might be some interim version(s) ) as i am in the middle of adding a drag/drop template builder for emails and print order history rather than having to mess around with filters/templates. it’s kind of a big job , so cannot really give you an exact ETA.

>I’m sure some businesses would find it useful, particularly during installation.

useful perhaps (up to an extend), but – to be honest – if the business does not know how to make sure their server sends emails, maybe they should get some qualified help in the first place.
…anyway, that’s a conversation for a different day