As indicated in my above link - XLSForm Docs - the uniqueness of id/instance_name is entirely dependent on how the form writer/designer chooses to define it. If they use a calculation incorporating uuid() then it’ll be unique across all forms and devices; if they use deviceid then it’ll be unique across devices but all the submissions from a particular device with have the same id/instance_name obviously, etc.
If you require a universally unique id - ie one that is pretty much guaranteed to be unique across all devices and submissions - then you’ll have a hard time getting away from uuid() [sic]. If you want a simpler id like 12345, this requires some sort of centralized id (ie ‘ticket’) generator that issues a new numeric (eg counter) id upon request. The problem is this model doesn’t work if you are collecting data offline - you fundamentally cant have a centralized ticket generator and offline data capture.
If you want to entirely avoid uuid(), you could construct a id using either deviceid, subscriberid or simserial (see ODK metadata for details), which should uniquely identify the device from which the submission originated. And then add to this (unique) string the form id (which should be unique wrt your organization), and then exploit ODKs so-called ExIntegerWidget to retreive a monotonically increasing counter from the ODK Counter app; as described here. That should give you a unique id string.
Which is all to say, generating truly unique ids offline, that is without some sort of centralized ticket generator, is fundamentally a tricky problem. This is why in many cases primary keys are generated by the database itself (eg using AUTO_INCREMENT), and not obtained from the client; the DB is basically acting as the ‘ticket’ issuer. And if you want to avoid client-generated uuids then you’ll probably have to perform some fairly involved technical acrobatics to accomplish it.
