No, because I use Linux.
I tried:
    find ~/ConTeXt -name scrn-fld.mkiv

But this did find nothing.

I also tried:
    find ~/ConTeXt -name '*fld*'

This gives:
/home/cecil/ConTeXt/tex/texmf-context/tex/context/base/scrn-fld.lua
/home/cecil/ConTeXt/tex/texmf-context/tex/context/base/java-fld.mkii
/home/cecil/ConTeXt/tex/texmf-context/tex/context/base/scrn-fld.mkii
/home/cecil/ConTeXt/tex/texmf-context/tex/context/base/lpdf-fld.lua
/home/cecil/ConTeXt/tex/texmf-context/tex/context/base/java-imp-fld.mkiv
/home/cecil/ConTeXt/tex/texmf-context/tex/context/base/scrn-fld.mkvi

Maybe the last one is wrong? .mkvi instead of .mkiv.


It starts with:
%D \module
%D   [       file=scrn-fld,
%D        version=1997.05.18,
%D          title=\CONTEXT\ Screen Macros,
%D       subtitle=Fields,
%D         author=Hans Hagen,
%D           date=\currentdate,
%D      copyright={PRAGMA / Hans Hagen \& Ton Otten}]
%C
%C This module is part of the \CONTEXT\ macro||package and is
%C therefore copyrighted by \PRAGMA. See mreadme.pdf for
%C details.

% There is still some leftover code from mkii, where we need to
% be sparse with hash entries and so have a somewhat complex
% setup mechanism.

% interaction checking

\writestatus{loading}{ConTeXt Screen Macros / Fields}

\unprotect

\registerctxluafile{scrn-fld}{1.001}

%D In \MKII\ we had to cheat a bit with setups in order not to run
%D out of memory with thousands of fields, which we happen to need at
%D that time. In \MKIV\ we can store some data at the \LUA\ end and
%D use a somewhat slower but quite okay inheritance mechanism. For
%D this reason we now have split definitions, although the old method
%D is still somewhat supported. The clone and copy commands are
%D somewhat obsolete for several reasons: we can now use inheritance
%D and autocloning has been supported for a while. In most cases
%D cloning (especially with check boxes) the acrobat browser is not
%D stable enough with respect to appearance handling.

So I'll look what happens if I rename it.