AviSynth 2.5, 2.6, any version of Plus, etc. honors the system locale. UTF-8 causes problems for AviSynth in one scenario, and only one scenario: the user has left Windows set at its regional default codepage (whether that's Windows-1252, -1251, -932, -936, -949, -950, etc.).
On Linux, macOS, and BSD, the system locale is UTF-8. AviSynth+ has no issues with it, without us having had to change any code at all to accommodate it. Text files created on these systems also usually default to UTF-8 without BOM anyway.
On Windows 10, Microsoft finally allows users to set the system codepage (locale) to 65001, which is UTF-8. If you do this, none of the versions of AviSynth, classic or Plus, have issues with it. Notepad in Windows 10, regardless of the locale, was switched to defaulting to save in UTF-8 without BOM a while ago.
Proving that this isn't something Plus-related, here's 2.6.1 running a UTF-8 encoded script with a UTF-8 filename, opening a video with FFMS2 with a UTF-8 filename (without passing any kind of special parameter to allow it), in a directory with a UTF-8 name: