So it's clear.
Old_Class loads old defined properties in a local Object structure 
and writes only this structure back.

It has no idea of New properties and doesn't write it.
Just a guess:
$LB(...) in ^GlobalD of Old_class is shorter than for New_class
 So %Save() of Old_class is a data killer.
 

OK,
but prerequisit is, that both definitions are identical.
Especially in the Storage definition, where properties are mapped to globals

a selphy ??  😉

ATTENTION ! This made me nervous.

In essence, the two classes are sharing the same data / Index / stream globals.

This means there is also
Parameter MANAGEDEXTENT As INTEGER = 0;

Otherwise, it wouldn't compile

Re-reading your question, I understand that properties in 
New_class are not identical and synchronized with Old_class ?
So even Storage Definition might be different ? 

IF YES, I'd say it's highly risky! 

• With %OpenId you create a complete internal local copy of your object
• With %Save it is written back as complete as is was. NOT just changed properties as you might expect And non- defined properties vanish
• Any change that happened in between from some other process is lost
• You may need some locking logic to prevent simultaneous access by 2 instances  eg. locking the Id for exclusive access by 1 single  process.
• In your case it may even happen in 1 process with Old_Class vs, New_Class

Big Thanks for this recognition  ! 
Especially for the team that made it possible. 

💐 

My personal approach would be:

1. separate instance code from Class Methods This covers all properties and especially Calculated Properties Or simplified, all code tied to data storage
2.  Class Methods work on referenced objects but have no dedicated data store (i%...) Simplified, they are code-only components.
3.  Class Methods could be bundled in several Classes.

YES, directly from MGMT Portal just as you do in Cachè
localhost:52773/csp/sys/mgr/%25CSP.UI.Portal.MemoryStartup.zen

by default YES

@Julius Kavay  hits the point:

true of false as system constants is breaking the rules and
the long-practiced idea and principles behind ISOS and before
( @Joel Solon : isn't it ?) 

You may ask for $TRUE or $FALSE  system constant / variable

Until this, you are free to define your own $ZTRUE or $ZFALSE using
%ZLANGV00.mac to extend the language.
It's all ready for use to extend the language according to your needs and taste

Details on %ZLANG*

I fail to see the problem:

• true:==> $$$OK
• false:==> $$$NOTOK

do I miss siómething ?

Or is the intention to mix ISOS with JavaScript ???

Did you use this kit from evaluation.intersystems.com/Eval/community-download ?
=> IRISHealth_Community-2025.3.0.226.0-macos.tar.gz

Primary / Secondary  ?? Is this a shadowing configuration ?

Shadowing applies to the databases  IRIS.DAT, and Journal Files  
It doesn't shadow external "foreign" files like  .../Temp/QWhoZAwFF3f9jQ.iostream

Done!  😎

Did you also run a rebuild index ?
Just defining is not enough.

If you use a custom class query %Library.Query type you may write your parameters to some
^mtemp.Evgeny($i(^mtermp.Egeny)) = ..... direct from the Execute method
or ^mtemp.Evgeny($h) = ....

For basic class query %SQL.Query () you may take the usual SQL approach

• Create a SQL method that always returns 1 (TRUE)
• You pass all your parameters into that method 
  • which does the ^mtemp trick and a QUIT 1
• add to the WHERE clause  . . .  AND MYTRACE(par1,par2,---)=1

I refer to this a STATIC clause since it is only executed once by query
because of no reference to any column values 

It was my approach to SQL debugging