Can you elaborate on how this has changed in LF11? 

The folder seems to have moved from ProgramData\Laserfiche Forms\RoutingError to ProgramData\Laserfiche\Forms\RoutingError, and I haven't seen anything accumulating there.

Instead, submission errors appear to accumulate in InvalidSubmissions. So far, everything I've found here has coincided with the approximate time of a SQL or Forms server restart, and moving the XML file from InvalidSubmissions to the corresponding folder under RoutingError has ended up processing the submission within a few seconds without further issue.

I'm just trying to understand how these files are supposed to work, so that I can adjust the notifications we have in place to catch them. At this point, I'm not sure how much of what we're observing is caused by the routing service instability we're dealing with.

You are correct on RoutingError folder that it is moved to ProgramData\Laserfiche\Forms\RoutingError.

In Forms 11, we make some changes to RoutingError submissions:

1. First of all, the RoutingError name is misleading, we actually use the folder to store submissions that IIS received in first hand. 

2. Further more, we've add a new db table submission_recovery in Forms database, that's now where unprocessed submissions are located, Forms web server will scan RoutingError folder regularly and move submissions that does not occur in Forms database in submission_recovery table.

3. Routing will read from submission_recovery table and try to process submissions inside it when it is idle so that you do not need to restart Routing Service to do recovery.

4. About InvalidSubmissions, we put submissions that occurred unexpected errors while processing in InvalidSubmissions folder. In our experience, these are mostly unrecoverable items such as invalid xmls saved. Routing does not try to recover items inside InvalidSubmissions folder. While in your case, you put them in RoutingError and routing processed them successfully, because they are acutally just unlucky valid submissions processed at a bad time.

Thanks for the info; this sounds like a good change!

Sounds like I still need to monitor the InvalidSubmissions folder, though. Some of the ones I found were initial form submissions, which I'm sure would have eventually been reentered. And since this folder doesn't get reprocessed, it avoids the problem that sparks my original post.

The others stalled a user task with the message "This task has been locked because a submission has already occurred but has not been processed."

Assuming that there will always be some sort of error condition from which Forms can't automatically recover a submission, I'd really like some built-in notification that a submission was lost, so I can at least attempt to parse out enough information to have someone contact the user and let them know their form needs to be resubmitted.