Um dos supostos benefícios das aeronaves elétricas (como o Volocopter) sobre helicópteros movidos a petróleo é o barulho.
Motores elétricos supostamente incomodariam menos quem vive perto das estações, mas não deu para saber se a aeronave era barulhenta porque o voo demonstrativo foi de algumas centenas de metros diante de repórteres. A essa distância, soava como um zangão que cresceu demais.
As caronas aéreas talvez não agradem a todos, mas o presidente da Volocopter, Florian Reuter, planeja usar software e a relativa liberdade de rotas aéreas para projetar viagens mais suaves para quem precisa. “Pode haver um modo vovó e um modo foguete”, ele brinca.
Outra questão é o custo. O diretor-gerente da Skyports, Duncan Walker, entende que as rotas inicialmente atenderão a turistas curiosos e a quem viaja a negócios e tem dinheiro para gastar, porém essas empresas esperam reduzir custos a ponto de disponibilizar o serviço para o mercado de massa.

Algumas aplicações poderão ser migradas facilmente para o .NET Core (especialmente as baseadas em ASP.NET MVC), mas outras devem enfrentar problemas, devido a mudanças e remoções de classes e APIs na nova plataforma. Além das dificuldades esperadas ao migrar de WinForms/WPF para Universal Windows Applications, existem questões mais sutis no .NET Framework que precisam ser levadas em consideração.
A API de reflexão mudou muito no .NET Core. Assim como o WinRT, foi "bifurcada" em uma versão leve e outra mais pesada. Sobre isso, Immo Landwerth da Microsoft escreve:
Com a criação do .NET Native, temos a tecnologia que permite fazer a vinculação estática da uma aplicação com frameworks e dependências de terceiros. Para isso, é importante que seja possível identificar as partes do framework que não estão sendo utilizadas. Em outras tecnologias, como C++, isso é relativamente simples, já que esses sistemas não possuem aspectos dinâmicos como reflexão.
O .NET Native ainda suporta reflexão, mas queríamos otimizar a plataforma, para que não se pague por funcionalidades não usadas. Isso é especialmente válido em reflexão, pois a reflexão impõe restrições sobre o que o ambiente de execução e os compiladores podem fazer com base em informações estáticas.
Idealmente, reflexão deveria ser um componente opcional no .NET Core, podend0-se tomar a decisão de não utilizá-lo. A parte complicada é que System.Object depende de reflexão devido ao método Object.GetType(). Para quebrar essa dependência, decidimos que System.Type deixa de representar a informação completa do tipo obtido via reflexão - mas somente o nome do tipo. Assim, System.Type no .NET Core não possui mais APIs como GetMembers(), mas continua expondo APIs como Name.
Um método de extensão chamado GetTypeInfo expõe o resto da informação que normalmente seria obtida do objeto Type. A classe TypeInfo não é mais tão rica quanto a original, mas a Microsoft decidiu recentemente trazer de volta algumas APIs de reflexão que não planejavam incluir no .NET Core.
Para tornar o código mais compatível, o .NET 4.5 (ou superior) suporta a versão de TypeInfo similar à do .NET Core.
Os App Domains (domínios de aplicações) são implementados pelo CoreCLR, mas não pelo .NET Native. Devido às exigências sobre o runtime para suportar essa funcionalidade, não há planos para incluí-la. A equipe da MS indica que "para isolar o código, recomendamos processos e/ou containers. Para o carregamento dinâmico de assemblies, sugerimos a nova classe AssemblyLoadContext."
Hoje poucos são os desenvolvedores que lembram da existência da biblioteca de execução remota (Remoting) do .NET; menos ainda se lembram como utilizá-la; e os que a conheciam frequentemente reclamavam de seu desempenho, complexidade e fragilidade.
Para aumentar o desempenho, a comunicação entre aplicações .NET em uma mesma máquina foi substituída pelo WCF, ou por pipes e arquivos mapeados em memória. Entre máquinas, a Microsoft recomenda "um protocolo textual com baixo overhead, como o HTTP". Ou seja, a empresa não planeja incluir execução remota no .NET Core.
A maioria dos serializadores como o serializador de contrato de dados (DataContract), o serializador de XML (XmlSerializer), o JSON.NET (Newtonsoft.Json), e o protobuf-net (Protocol Buffers) são suportadas no .NET Core. A principal exceção é a serialização binária.
Após uma década criando e mantendo serviços, aprendemos que serialização é extremamente complexa e que gera um peso imenso em compatibilidade para os tipos que suportam a funcionalidade. Tomamos a decisão que serialização deve ser um protocolo implementado em cima das APIs públicas disponíveis. Contudo, a serialização binária requer conhecimento profundo dos tipos, pois permite serializar grafos de objetos, incluindo o estado privado dos objetos.
Em teoria, o sandboxing é uma ótima ideia; permite a execução de código parcialmente confiável de maneira segura. Na prática, é muito difícil implementar sandboxing de maneira correta e qualquer pequeno erro leva a vulnerabilidades de segurança. Immo Landwerth, da MS, diz que isso "torna a implementação mais complicada e muitas vezes afeta a performance de forma negativa das aplicações, mesmo das aplicações que não usam sandboxing".
A alternativa recomendada é iniciar processos separados que executam sob uma conta de usuário permissões restritas. Dessa maneira, o ambiente de execução não precisa duplicar a verificação custosa de permissões já realizada pelo sistema operacional.
Os componentes na lista abaixo estão sendo considerados (no momento de escrita) para serem tornados open source e migrados para o .NET Core.
[Desde a publicação da notícia original, houve muito progresso na criação das funcionalidades abaixo no .NET core; confira o que já está disponível aqui.]
System.Data. Embora sua camada base já seja parte do .NET Core, como o modelo de provedores (Data Providers) e o cliente SQL (SqlClient), algumas funcionalidades não estão disponíveis, como o suporte a esquemas de banco de dado e DataTable/DataSet.
System.DirectoryServices. Nesse momento não há suporte para comunicação com LDAP ou Active Directory no .NET Core.
System.Drawing. Embora seja essencialmente uma API cliente, muitos desenvolvedores usam System.Drawing no servidor para gerar miniaturas ou marcas d'água. No momento não há suporte a essas APIs no .NET Core.
System.Transactions. O ADO.NET suporta transações, mas não há suporte a transações distribuídas, o que inclui a noção de ambiente de transação.
System.Xml.Xsl e System.Xml.Schema. O .NET Core suporta o XmlDocument e o XDocument do Linq, incluindo XPath. Porém, não há suporte no momento para XSD (XmlSchema) ou XSLT (XslTransform).
System.Xaml. Ao criar aplicações UWP, desenvolvedores utilizam APIs XAML do WinRT. Sendo assim, o .NET Core não traz o framework de XAML gerenciado, o que inclui a capacidade de interpretar documentos XAML e instanciar o grafo de objetos descrito.