Answer
Yes, all three observations are accurate. Certain IDs genuinely can't (or shouldn't) be system-defaulted, because they're usually driven by an external numbering scheme the organization already has (an engineering-planned part-numbering format, a supplier's own sequence, or some other pre-established convention) rather than something IFS should auto-generate. Correcting a record's key fields via a trigger before the initial insert is impractical in the standard framework; validation can reject an invalid entry, but can't silently fix it for the user. And once key identifying fields are saved on many LUs (Customer ID, Customer Order Number, Purchase Order Number, Part Number, Voucher Number, and others), they become effectively permanent — the only remaining options are deleting the record (if the record type allows deletion) or cancelling it, never editing the ID in place. Despite these constraints, using LU IDs as genuine functional/reference fields is still the right approach rather than fighting it — IFS's interconnected design already assumes IDs are used this way throughout the system, and building your own parallel identity-management layer on top just to avoid this reality tends to cost more than it saves. The practical path is accepting these as 'one-way doors' once crossed, focusing your actual control efforts on configuring the identity/numbering sequence defaults where that genuinely is configurable, and building your organization's own data-entry discipline and validation rules around living with these constraints rather than trying to eliminate them.