Con l'ultima build di Windows 10 19H1 è possibile accedere ai file sul Windows Subsystem for Linux

Non vedo perché Windows debba essere riscritto per piegarsi all'utilizzo di filesystem alieni al suo ecosistema.

E' corretto, comunque, ciò che scrivi, anche se il problema dei metadati necessari a Windows (NT+++++) si potrebbe risolvere con soluzioni tipo quella di MacOS X che piazza file .DS_Store nei dispositivi formattati con filesystem diversi dai suoi. E' un accrocco, ma comunque funzionerebbe.

Ha senso farlo? Non in ambito Windows, dove a parte NTFS, FAT32, exFAT, Joliet etc., non c'è alcun interesse ad accedere ad altri filesystem.

Il nocciolo rimane ciò che ho scritto prima: le implementazioni dei filesystem scritti per s.o. diversi da Windows fanno uso di API (e ABI) ben diversi, e richiederebbero troppi adattamenti o addirittura riscritture. Specialmente se provenienti da Linux, dove non esiste il concetto di API & ABI stabili, visto che li cambiano quando vogliono (per questo pretendono di avere i sorgenti di driver e applicazioni: per poterli adattare).

D'altra parte se fosse così facile fare porting, considerata l'eterogeneità delle API/ABI messe a disposizione da ogni s.o., non ci sarebbe gente che a ogni occasione si chiede perché certe applicazioni non siano portate su altri s.o.. Ovviamente (ma tanto ovvio non è, a quanto pare. D'altra parte nemmeno tanti programmatori si fanno problemi a spararle grosse quando si parla di queste cose) non è affatto così semplice; tutt'altro.

Oltre al fatto che i filesystem sono pezzi di codice fra i più critici (per ovvi motivi) e che, quindi, richiedono sviluppo, manutenzione, e testing di gran lunga più lunghi e pesanti rispetto ad altre applicazioni.

Infine, non l'avevo scritto prima per non appesantire il discorso ma a questo punto lo aggiungo per completezza, c'è il problema delle licenze. Usualmente roba proveniente da Linux è GPL, che è una licenza virale. E siccome un filesystem è interfacciato col kernel, è possibile che tale codice possa infettare quello del kernel che ne fa uso, generando un'infezione che potrebbe arrivare ad attaccare anche buona parte del s.o., coi danni che si possono facilmente immaginare.
Per cui sarebbe di gran lunga più conveniente riscrivere completamente l'implementazione di un filesystem, che prenderne un'altra (e chissà come sarebbe scritta, peraltro) accollandosi tutti i rischi del caso.