IronPython3 PlatformNotSupportedException in .NET WASM

Maybe this is a regression based on the PR here, seemingly indicating that it was the fix to make IronPython3 work with Blazor: https://github.com/IronLanguages/dlr/pull/256
Though this issue remained open on IronPython2 (but again indicated the scenario should work in IronPython3): https://github.com/IronLanguages/ironpython2/issues/769

I'm in an Uno Platform WASM context (should be the same as Blazor). And when I tried to call CreateEngine I got this exception (which looks like it's trying to find the console, though that was what the above PR was supposed to fix?):

System.Reflection.TargetInvocationException: Failed to load language 'IronPython 3.4.2': Operation is not supported on this platform.
 ---> System.PlatformNotSupportedException: Operation is not supported on this platform.
   at System.ConsolePal.get_InputEncoding()
   at System.Console.get_InputEncoding()
   at Microsoft.Scripting.Runtime.SharedIO.InitializeInput()
   at Microsoft.Scripting.Runtime.SharedIO.get_InputEncoding()
   at IronPython.Modules.PythonIOModule.CreateConsole(PythonContext context, SharedIO io, ConsoleStreamType type, String name, StreamBox& sio)
   at IronPython.Runtime.PythonContext.SetStandardIO()
   at IronPython.Runtime.PythonContext.InitializeSystemState()
   at IronPython.Runtime.PythonContext..ctor(ScriptDomainManager manager, IDictionary`2 options)
   at System.Object.InvokeStub_PythonContext..ctor(Object , Span`1 )
   at System.Reflection.MethodBaseInvoker.InvokeWithFewArgs(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   --- End of inner exception stack trace ---
   at Microsoft.Scripting.Runtime.LanguageConfiguration.LoadLanguageContext(ScriptDomainManager domainManager, Boolean& alreadyLoaded)
   at Microsoft.Scripting.Runtime.DlrConfiguration.LoadLanguageContext(ScriptDomainManager manager, LanguageConfiguration config)
   at Microsoft.Scripting.Runtime.DlrConfiguration.TryLoadLanguage(ScriptDomainManager manager, AssemblyQualifiedTypeName& providerName, LanguageContext& language)
   at Microsoft.Scripting.Runtime.ScriptDomainManager.GetLanguageByTypeName(String providerAssemblyQualifiedTypeName)
   at Microsoft.Scripting.Hosting.ScriptRuntime.GetEngineByTypeName(String assemblyQualifiedTypeName)
   at IronPython.Hosting.Python.GetEngine(ScriptRuntime runtime)
   at IronPython.Hosting.Python.CreateEngine()

Perhaps some similar try/catch fallback helper logic to https://github.com/IronLanguages/dlr/pull/256 needs to be implemented here?

https://github.com/IronLanguages/ironpython3/blob/71a8f5ca374ae6ebe7d746d674090e51b5160ab3/src/core/IronPython/Runtime/PythonContext.cs#L1862-L1868

I don't need input in my scenario, and plan to redirect the output already. Though not sure if there'd be other blockers beyond this.

Already been poking at this too late today, but will see if I can build the repo and investigate, VS doesn't seem to let me step-in to the function in the WASM debug context for some reason.

Start with the CreateEngine failure in the reported Uno Platform WASM context and read PythonContext.cs at lines 1862-1868, then compare the fallback logic in DLR PR 256. Reproduce the PlatformNotSupportedException and determine whether engine creation can complete without console input; done means the reported WASM scenario no longer fails at this point.