Pra mim pode ser um "redflag" se ele depender do Windows pra programar.

Sendo bem sincero nunca perguntei se um desenvolvedor utilizava Windows ou Linux durante uma entrevista. Não tem a ver com o SO. Se você decide por um desenvolvedor que ele deve usar X ferramenta ao invés de Y, há dois aspectos principais:

• Curva de aprendizado
• Disposição

O redflag está aí. Eu, como líder técnico, sempre me coloco à disposição para auxiliar com a curva de aprendizado. Mas se ele não está disposto a enfrentar esta curva, ele não vai ser produtivo, independente do SO.

Na minha equipe todos trabalhamos primariamente com Python. Não há qualquer imposição direta de ferramentas como IDE e sistema operacional.

Mas a questão é que temos uma diretriz sobre nosso estilo de código (famosa PEP-8). E para reforçar a diretriz, há uma verificação que faz parte da nossa pipeline de CI. Se o desenvolvedor não conseguir garantir um código dentro destas diretrizes, a pipeline irá falhar e o PR não prosseguirá. Não me importa muito se ele prefere PyCharm ou VSCode, Windows ou Linux, etc.

Mas se a maioria usa VSCode, e alguém decide usar o PyCharm, ele assume a responsabilidade de descobrir sozinho como configurar corretamente para que o resultado seja consistente, e acaba tirando menos proveito das descobertas dos demais. Isso naturalmente encoraja a uma padronização.

Obviamente esta liberdade de escolha depende da maleabilidade que o sistema possui em se adequar ao sistema de arquivos da máquina. Eu trabalhei isso desde quando decidimos reescrever o sistema. É mais fácil quando é pensado pra ser assim desde o zero.

Além do que você já pontuou sobre o caminho do volume, como a aplicação resolve o caminho das subpastas? Se for através de uma concatenação de string simples, pode dar ruim pois pode resultar em algo do tipo D:\\host\\path\\no\\windows/resto/do/path, ou você pode tentar fazer a separação do caminho (famoso split ou slice) manualmente levando em conta o separador incorreto. Dependendo do caso gera erros. Isso significaria ter de refatorar todo o código para usar um método programático, através de bibliotecas que lidam com o sistema de arquivo, pra formar um caminho adequado para o sistema que estiver executando dinamicamente.

Eu passei a dar mais atenção a este tipo de "detalhe" após ler o Twelve-factor App. Recomendo, e é bem curto.

Mas aí refatorar nunca é uma decisão simples, e nem sempre o melhor caminho. Leve em consideração tempo e recursos disponíveis e envolvidos na alteração, os benefícios reais que esta transição irá trazer, etc, porque como líder você deve observar antes de tudo a integridade do projeto. Não dá pra deslocar seu roadmap em 1 mês simplesmente porque 2 desenvolvedores usam Windows e se recusam a usar Linux. Diga isso em uma reunião de produto (quando não de diretoria, em último caso) e provavelmente perderá pontos com pessoas importantes/influentes.