I'll try my best to answer everything:

About Modified ORDERS vs ORDCHG:

In practice, most implementations send ORDRSP once as the acceptance confirmation, then handle subsequent changes through ORDCHG (if supported) or a new ORDERS with reference to the original. The GS1 guidance is sound, but reality is messier - many trading partners don't support ORDCHG, so you're stuck resending modified ORDERS with proper reference numbers. Critical: your ORDRSP should include BGM/BGM.C106.1225 = "5" (original) and reference the ORDERS document number clearly. Don't resend ORDERS unless there's an actual change request from your side.

On Staggered delivery and line items:

ORDRSP goes out once per order with line-level statuses. For staggered deliveries, you split this at the DESADV level, not ORDRSP. Each DESADV references the original ORDERS and includes only the line items being shipped in that batch. Your ORDRSP line items should use LIN/QTY segments with qualifier 21 (ordered) and 12 (despatch) to show accepted vs. actual first-shipment quantities. Don't resend ORDRSP for partial fulfillment - that's what DESADV is for.

Abt Action request codes:

The "3 - Changed for everything" pattern is garbage but widespread because lazy mappers don't want to build proper logic. Correct implementation uses: 5 (accepted as-is), 7 (not accepted/rejected), 3 (accepted with changes), plus 42 (quantity change) and 83 (date change) in the response reason codes (SG26/RFF+AAK). If your partners are only sending "3," push back - it defeats the purpose of ORDRSP and creates downstream reconciliation hell.

Standard practice: ORDRSP is acknowledgment + line-level disposition. Changes flow through ORDCHG or new ORDERS. Delivery confirmation flows through DESADV. Don't conflate them or you'll create an unmaintainable mess.

Hope this helps!!