Following this discussion since beginning I'm wondering about the variant I've learned.
my personal approach would be.
#1)
have an exact copy of your class also pointing to the same storage
remove all index definitions from that clone class
run your bulkload
#2)
if you don't want to have the same storage
just eliminate the index definitions in the copy
clean its storage and run your bulk load
finally, merge the resulting globals

#' .)
It's not pure OO,
but writing to storage is never OO with Caché or IRIS 

GREAT!
Looks like embedded Py starts to understand how IRIS really works inside !!!!    

fully support this urgent improvement  !

that makes sense. 
version dependency is always a pain!  

I'd say it's a bug in Query Generator.
A workaround in DB-API just might hide the real cause. 
If you are lucky the bug is fixed by the next release or the next after or some future release

I fail to imagine how to do this with ePy  

thanks for confirming my diagnose
- that's why I used "+id as id1" to break the link to index global
- and :BTW:   ORDER BY 1  ; just using column position shows the same bug

Why would you want to do this?
the index related to %Save() is no "build" but just setting a value to the index global. 
setting an index is mostly less load than saving an object.

see this article: Date before Dec.1840 ? Negative $H(orolog) ?

A possible workaround 

SAMPLES>set rs= ##class(%SQL.Statement).%ExecDirect(,"SELECT +id id1, x, y, z FROM some_table ORDER BY id")

SAMPLES>while rs.%Next() { zwrite $listbuild(rs.id1, rs.x, rs.y, rs.z) }
$lb(1,1,2,"z1")
$lb(2,2,3,"z2")
$lb(3,3,4,"z3")
$lb(4,4,5,"z4")

SAMPLES>

The point is to consume your value NOT from temp order global.

tested in 
Cache for Windows (x86-64) 2018.1.7 (Build 721U) Fri Mar 18 2022 22:07:35 EDT
Should also work in IRIS

terminate your Dockerfile with  USER irisowner as last line

Just as described here

you need to check the already used connections.

and code quality will struggle with it and dislike it

because you use name in write, but you don't set it explicitly

but don't care much about:
it doesn't understand %-variables and global variable scopes
and $$$macros with code inside, and ... and ... and  

to get control over your situation you have 2 key methods:

• $SYSTEM.License.MaxConnections() returns the maximum number of connections a user can make while consuming one license unit.
• $SYSTEM.License.ConnectionCount() returns the number of connections currently associated with the given UserIdentifier. The range of return values is normally 0 through MAXCONNECTIONS. If the value exceeds MAXCONNECTIONS then more than the allowable number of concurrent connections were attempted for a given ID and the system has transitioned to a mode of one connection per license for this UserIdentifier.

So you have to check if your user has exhausted its available connections and block him.
It's anyhow quite interesting how these users are able to trigger so many connections.

I share your suggestion!

When I started with Docker I was highly skeptical after many years with VMware starting before their first release.
It was a hard exercise and I took quite a while digging through docs and helps.
My main problem was that everything was so generic and not at all specific to IRIS (or Caché).

Meanwhile, it became so common to me that I stopped running reviews on packages without docker.
Docker allowed me to have a "clean desk" after testing.
In addition. I saw through this activity so many valid variations that
I doubt to decide how to start and where.
On the other hand, I see in OEX ~450 tested and working examples (a dozen PR still pending) 
Following these examples and trying to understand what will be achieved
could be good food for training designers. 
 

nothing prevents you to load this script at runtime from server.

<script src="myscripts.js"></script> 
from w3schools.com https://www.w3schools.com/tags/att_script_src.asp

So you are outside your Caché