nowhere.  It's the purpose of deployed code not to be hacked nor debugged

GREAT!
>> unless perhaps the right person at InterSystems is reading this and gets the change put into the products. <<
My hope is with you!

But even if you place a Prodlog / Change Request it might be a matter of years [plural] to see this in production. 
 Always assuming the "priests of the security grail"  don't oppose. 

There is a bunch of auto-generated methods that might be useful:
https://community.intersystems.com/post/useful-auto-generated-methods

especially this one from @Eduard Lebedyuk 
#############################################################

But with PropertySetObjectId you can expedite things

set person = ##class(Person).%New()
set companyId = 123
do person.EmployedAtSetObjectId(companyId)

The main advantage is that company object doesn't have to be opened.

#############################################################

an example of a self-referencing 1:1 relationship
it is also characterized by our "implicit join" feature  ->

Class Sample.Person Extends (%Persistent, %Populate)  {
 - - - 
 Property Spouse As Sample.Person
 Index sp On Spouse [ Unique ]; // to verify 1:1    
 - - -
 }

the format ./IOTABLE="CP1252" applies only using the OPEN command

$ZCONVERT and %Stream.FileCharacter  just use "CP1252" just by the name

In namespace %SYS you have a utility NLS that shows your installed conversion table and its short names.

%SYS>d ^NLS
2) Select defaults
2) I/O tables
Items marked with (*) represent the locale's original default
 I/O table              Current default
---------------------  --------------------
1) Process             RAW (*)
2) Cache Terminal      UTF8 (*)
3) Other terminal      UTF8 (*)
4) File                RAW (*)
5) Magtape             RAW (*)
6) TCP/IP              RAW (*)
7) System call         RAW (*)
8) Printer             RAW (*)
 
I/O table: 4
 
 1) RAW (*)                              2) UTF8
 3) UnicodeLittle                        4) UnicodeBig
 5) CP1250                               6) CP1251
 7) CP1252                               8) CP1253
 9) CP1255                              10) CP437
11) CP850                               12) CP852
13) CP866                               14) CP874
15) EBCDIC                              16) Latin2
17) Latin9                              18) LatinC
19) LatinG                              20) LatinH
21) LatinT

So you see the shortnames but no Latin1  but CP1252 which is almost identical.
the related problem is described here:
 https://www.i18nqa.com/debug/table-iso8859-1-vs-windows-1252.html

"ISO-8859-1 (also called Latin-1) is identical to Windows-1252 (also called CP1252) except for the code points 128-159 (0x80-0x9F). ISO-8859-1 assigns several control codes in this range. Windows-1252 has several characters, punctuation, arithmetic and business symbols assigned to these code points."

and Encoding Problem: ISO-8859-1 vs Windows-1252
So you should check what your customer really does (some hide the fact they use Windows)

The appropriate table can be used in

• $ZCONVERT(),
• ##class(%Stream.FileCharacter ) property TranslateTable
• OPEN command parameter /IOTABLE=

SUPER ! 

Robert

Sorry!  That doesn't indicate any reason. $zf(-1) is just a spawn.

using LOG^%ETN gives a full stack trace. without breaking the process
you just have to place it into your code at the critical points.
https://docs.intersystems.com/iris20201/csp/docbook/Doc.View.cls?KEY=GCOS_errors#GCOS_errors_log_etn

Instead of the double $ZF()  I'd suggest using the query in Library class %File.

 
set rs=##class(%ResultSet).%New("%File:FileSet")
do rs.Execute(SDIR,"*",1)
while rs.Next() { write !,rs.GetData(1) }