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.

@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*

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
 

Class MyPackage.MyClass Extends (%Persistent, %JSON.Adaptor)
{
 Property JSONid As %Integer(%JSONFIELDNAME = "id");
 Property strprop As %String;
 Property boolprop As %Boolean;
}
                                                                           

next this worked

set jsn={  "id": 1,  "strprop": "string", "boolprop": true }
set sc=obj.%JSONImport(jsn)
zw obj
+----------------- general information ---------------
|      oref value: 2
|      class name: MyPackage.MyClass
| reference count: 1
+----------------- attribute values ------------------
|       %Concurrency = 1  <Set>
|             JSONid = 1
|           boolprop = 1
|            strprop = "string"
+-----------------------------------------------------

$system.SQL.SetIdentityInsert(1) is deprecated and replaced by $system..SQL.Util.SetOption(IdentityInsert ,1) 

from class docs:>>>
https://docs.intersystems.com/irislatest/csp/documatic/%25CSP.Documatic.cls?LIBRARY=%25SYS&CLASSNAME=%25SYSTEM.SQL.Util#METHOD_SetOption

IdentityInsert - Set the IDENTITY_INSERT option for this process. IDENTITY_INSERT
controls the ability of the user to specify a value for the IDENTITY property when
saving a new object, a value for the IDENTITY column, or an explicit ROWID value in an SQL INSERT.

Notes

  • Changing this configuration setting takes effect immediately and lasts for the duration of the process or until $SYSTEM.SQL.Util.SetOption("IsolationMode",pValue) is called again.
  • This is a per-process setting.

Sounds good to me 

As I expected, it's one of the new storage features that cause the irritation

/// Use hashed global names
Parameter USEEXTENTSET = 1

from docu  https://docs.intersystems.com/iris20253/csp/docbook/DocBook.UI.Page.cls?KEY=GOBJ_storageglobals#GOBJ_storageglobals_hashed

When you set USEEXTENTSET to 1, each index is also assigned to a separate global, instead of using a single index global with different first subscripts. Again, this is done for increased performance.

Not explicitly mentioned - this also affects  IDKEY !

And the example presented shows in detail that 
IdLocation and DataLocation are NOT identical anymore, as it used to be for decades
 

You can get the required Global reference like this programmatically:

 ; get compiled class  with your classname
USER>set classname="oex.Dir"
USER>set dic=##class(%Dictionary.CompiledClass).%OpenId(classname)
 ; get relationship to CompiledStorage
USER>set stor=dic.Storages.GetAt(1)
 ; get name of the ID-Global
USER>Write stor.IdLocation
^oex.DirD
USER>