Currently we use a fixed "templates" (actually documents) in instdir/share/template/shellnew to create new documents using shell's "New" context menu on Windows - it takes the path to the source document from registry (FileName value in e.g. HKEY_CLASSES_ROOT\.odt\LibreOffice.WriterDocument.1\ShellNew) and copies it to the destination.

Some problems with this approach are:

1. The templates are in instdir, which is not modifiable by user without admin rights;
2. If user modifies the path to the templates, it is re-written at each LO update (bug 94857);
3. The template is a document with all the usual properties (styles, formats, languages, creation dates, editing times, ...) that don't match the settings defined in LibreOffice for new documents (default fonts or custom templates, locale-dependent options like default page format, localized style names etc.) (bug 35912, bug 48344, bug 90286, bug 91172, bug 120141, bug 122190).

There are some possible ways to improve the situation:

1. Try to improve the templates themselves. E.g., find out what might be removed from the ODF package to still be a valid ODF, yet not include the information that must be set to default when opened in LibreOffice. That might be possible for some properties; yet for sure, that wouldn't be possible for all of them, and in any case, it won't allow to reset to settings of *default custom template* configured by user.
2. Add a special setting into app-specific settings in settings.xml, which would tell LibreOffice to reset everything to defaults on open (and drop the setting, naturally). Possibly the best option.
3. Implement tdf#124877 (a command-line argument to create new empty documents), and use it in the ShellNew's Command value [1]. That would mean that when user clicks the context menu, LibreOffice process starts, loads the required module (e.g. Writer) to create the document, saves it to the specified location, and exits. Too much overhead IMO.
4. Implement tdf#123476 (consider file extension when opening 0-byte files to create new files of proper type), and use it not only for MS Office document types (compatibility hack), but also for ODF extensions. Would be non-standard, but *presumably* OK since intended for immediate opening with LibreOffice, which would convert that into proper documents on save.

I suppose that any of those approaches would not only fix problem #3, but also eliminate the *need* to modify templates (problem #1) or configure non-standard paths in ShellNew, thus obsoleting bug 94857 (problem #2).

[1] https://docs.microsoft.com/en-us/windows/win32/shell/context