Should not the gtest be added to buildInputs? So that FindGTest.cmake can discover it?

Hmm, even if I remove the split outputs, result/lib/cmake/GTest/GTestTargets.cmake will still be broken:

set_target_properties(GTest::gtest PROPERTIES
  INTERFACE_COMPILE_DEFINITIONS "GTEST_LINKED_AS_SHARED_LIBRARY=1"
  INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}//nix/store/cg7qb5dch7gd6rgpxz2c00xvqwxb4lwc-gtest-1.8.1/include"
  INTERFACE_SYSTEM_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}//nix/store/cg7qb5dch7gd6rgpxz2c00xvqwxb4lwc-gtest-1.8.1/include"
)

I have just recently fixed the same issue in openjpeg but they do not use generated export files like gtest does.

arrow-cpp has a custom FindGTest, it ignores cmake modules provided by gtest: https://github.com/apache/arrow/blob/apache-arrow-0.11.1/cpp/cmake_modules/FindGTest.cmake

I have just noticed that now gtest installs libgtest_main.so which can't be used as a main: gtest is right to assume that libgtest_main is static. EDIT: or may main of the program be defined in a shared library? EDIT2: it may.

I tried patching gtest and it now produces correct config files but the correct version is still not used, I am not sure where does the gtest 1.8.0 come from https://github.com/jtojnar/nixpkgs/pull/new/gtest

I don't know the exact origin of 1.8.0, but when GTEST_HOME is not set, arrow-cpp uses ExternalProject_Add(googletest_ep) instead of find_package(GTest): https://github.com/apache/arrow/blob/apache-arrow-0.11.1/cpp/cmake_modules/ThirdpartyToolchain.cmake#L489
This package build system is too convoluted. If our gtest does not match its expectations (static and not split), I'd let it use its own rather than patch it in Nixpkgs.

Using vendored builds will requires network access during the build and that's not allowed in restricted build on Hydra. You could try to implement download using fetchurl. The easier way is to just use symlinkJoin like it's done everywhere else in the expression.