SPSS Statistics v25 Unicode default change: managing mixed-version syntax repositories without a migration utility

Context

SPSS Statistics v25 switched the default SET UNICODE setting from OFF (v24 and earlier) to ON. Syntax files saved under the old default use the system locale code page (e.g., Windows-1252), while v25+ saves as UTF-8. This creates encoding mismatches when sharing syntax libraries across versions 24–29, especially for string literals, variable labels, and data values containing non-ASCII characters.

Goal

Establish a reliable workflow for a team that must maintain a single syntax repository compatible with both v24 (UNICODE=OFF default) and v25+ (UNICODE=ON default) installations, without relying on manual per-file conversion or per-session SET UNICODE overrides.

Constraints and uncertainty

• IBM documentation does not specify a supported automated migration path or batch conversion utility for legacy syntax libraries.
• No project-level encoding declaration (analogous to Python's # -*- coding: -*-) exists in SPSS syntax to declare file encoding explicitly.
• Changing SET UNICODE mid-session does not re-encode already-loaded string data; only subsequent read/write operations respect the new setting.
• Third-party editors may save files with or without BOM, interacting unpredictably with SPSS's encoding detection.

Questions

1. Is there an undocumented or community-maintained batch tool that can reliably convert a directory of .sps files from locale code page to UTF-8 (or vice versa) while preserving string literal semantics?
2. Can a wrapper script reliably detect and set the appropriate SET UNICODE state at runtime based on the SPSS version detected via SHOW UNICODE or SHOW VERSION?
3. What is the minimal set of explicit SET UNICODE directives needed at the top of each syntax file to guarantee identical behavior on v24 and v25+ without requiring developers to remember the version-specific default?