diff --git a/Documentation/sources/Reference/ofxPackaging.rst b/Documentation/sources/Reference/ofxPackaging.rst
index 9581662c..e90e6eaf 100644
--- a/Documentation/sources/Reference/ofxPackaging.rst
+++ b/Documentation/sources/Reference/ofxPackaging.rst
@@ -80,8 +80,11 @@ Where...
 
    -  ``MacOS`` - for Apple Macintosh OS X universal or architecture-specific binaries
    -  ``MacOS-x86-64`` - *DEPRECATED*. Formerly used for Intel Macs during the transition from PowerPC.
-   -  ``Win32`` - for Microsoft Windows (compiled 32 bit)
-   -  ``Win64`` - for Microsoft Windows (compiled 64 bit)
+   -  ``Win32`` - for Microsoft Windows (Intel x86, 32 bit)
+   -  ``Win64`` - for Microsoft Windows (Intel x64, 64 bit)
+   -  ``Win-arm64ec`` - for Microsoft Windows (ARM64EC)
+   -  ``Win-arm64`` - for Microsoft Windows (ARM64)
+   -  ``Win-arm64x`` - for Microsoft Windows (ARM64X)
    -  ``IRIX`` - for SGI IRIX plug-ins (compiled 32 bit) (*DEPRECATED*)
    -  ``IRIX64`` - for SGI IRIX plug-ins (compiled 64 bit) (*DEPRECATED*)
    -  ``Linux-x86`` - for Linux on x86 CPUs (compiled 32 bit)
@@ -107,24 +110,48 @@ binaries (since the plug-in .ofx file must always be named to match the
 top-level bundle name), but it should not be difficult for any plug-in
 to merge multiple architectures into a single binary on MacOS.
 
+Windows Architectures
+^^^^^^^^^^^^^^^^^^^^^
+
+As of 2024, Windows supports Arm64 CPUs. It uses two distinct ABIs,
+*Arm64* for native code, and *Arm64EC* for x64/Arm64 compatibility, in
+which x64 apps running in emulation on Arm64 hardware can interoperate
+with x64 DLLs (also in emulation) or Arm64EC DLLs (which are native
+Arm64 code with x64-compatible calling conventions). Arm64EC apps
+cannot load native Arm64 DLLs, only Intel or Arm64EC.
+
+Windows also supports an Arm64X "fat" binary PE format which
+contains both Intel/Arm64EC and Arm64 binaries.
+
+**Search Order**: Since apps built natively for Arm64 ("Arm64" abi)
+can only load Arm64 DLLs, those apps should attempt to load plugins
+from the "Win-arm64" folder first, then "Win-arm64x". Arm64EC hosts
+(running on an Arm64 system) should try the "Win-arm64ec" folder
+first, then "Win-arm64x". Arm64EC hosts can also use x64 DLLs, so they
+may try "Win64" as well, but should prefer the other folders to avoid
+running the plugin in emulation. An Arm64X host will be running either
+its Arm64EC branch or its Arm64 branch depending on how it's launched,
+so it should load plugins according to the above depending on the
+current mode.
+
+Note that there is no "fat binary" format on Windows that contains
+Intel x64 *and* arm64 code.
+
 Future Architecture Compatibility
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 NOTE: this section is not yet normative, but informational.
 
-Note that Windows and Linux do not support universal binaries. Each
+Note that Linux does not support universal binaries. Each
 .ofx file is for one architecture, so a host must check the proper
-architecture-specific subdir.
+architecture-specific subdir. Windows on Arm64 processors is similar.
 
-When Windows and/or Linux support alternative processor architectures
+When OpenFX apps on Linux support alternative processor architectures
 such as arm64, hosts should look in appropriately-named subdirs for
-the proper .ofx plugin file. On Windows with arm64, ``Win-arm64``
-should be used (vs. current ``Win32`` and ``Win64`` which are
-Intel-specific). On Linux, hosts should look in the subdir named by
-``Linux-${uname -m}`` which for arm64 should be ``Linux-aarch64``.
-Using ``uname -m`` rather than a hard-coded list allows for
-transparently supporting any future architectures.
-
+the proper .ofx plugin file. On Linux, hosts should look in the subdir
+named by ``Linux-${uname -m}`` which for arm64 should be
+``Linux-aarch64``. Using ``uname -m`` rather than a hard-coded list
+allows for transparently supporting any future architectures.
 
 
 Structure
diff --git a/release-notes.md b/release-notes.md
index d6a2de84..bd7f1e95 100644
--- a/release-notes.md
+++ b/release-notes.md
@@ -17,13 +17,14 @@ This is version 1.6 of the OpenFX API.
 
 ## Key Features of OpenFX Version 1.6:
 
-## Fixes in OpenFX Version 1.6:
+## Fixes
 
 ## Deprecations
 
 ## Detailed List of Changes
 
 - Add `kOfxImageEffectPropNoSpatialAwareness`. Allows the host and plugin to coordinate a render that ensures no spatial changes to the image.
+- Add plugin install locations for Windows Arm64
 
 # Release Notes - 1.5