Como 'ejetar' obtém processos para fechar identificadores de arquivo?

Não. Ele apenas desmonta o sistema de arquivos, portanto, quando um programa tentar acessar novamente o sistema de arquivos, haverá um erro (e esperamos que tente resolver as coisas sem problemas).

Não muito diferente no caso de você desconectar fisicamente um disco externo (ou pen USB). O sistema de arquivos não está mais disponível, mas os programas o verão logo após o primeiro uso.

Eu não sei, mas com um stick USB aleatório e um programa

$ df | grep Vol
/dev/disk1s2  12228  20  12208  1%  512  0  100%   /Volumes/Firmware
$ perl -E 'say $$; chdir "/Volumes/Firmware" or die "nope $!"; sleep 9999'
66433

Podemos realmente interromper a ejeção, mas antes disso precisamos de alguma depuração do processo, aqui fornecida pelo DTrace executado em algum outro terminal

$ sudo dtruss -p 66433
...

E então, através do que em inglês é chamado de botão de ejeção forçada, alguns cliques e atrasos e avisos posteriores, o programa de teste ainda está em execução e o pendrive desmontado e dtrussnão mostrou nada:

...
^C
$ lsof -p 66433 | grep cwd
perl5.26 66433 jhqdoe  cwd        cwd|rtd info error: No such file or directory
$ 

Portanto, pelo menos para um programa unix padrão, nada aconteceu além do ponto de montagem sendo removido dele. Em seguida, podemos testar a gravação de algo no ponto de montagem, novamente com um programa unix padrão

$ cat writeslow
#!/usr/bin/env perl
use 5.14.0;
use warnings;

open( my $fh, ">", "/Volumes/Firmware/mlatu" ) or die "nope $!";
while (1) {
    syswrite( $fh, "mlatu\n" ) or warn "hmm $!";
    sleep 3;
}
$ perl writeslow

e em outro lugar, confirmamos que os gatos estão aparecendo (o buffer pode ser um problema se você usar alguma função de gravação de nível superior)

$ cat /Volumes/Firmware/mlatu
mlatu
mlatu
$ 

e novamente forçamos a ejeção, e o programa percebe isso (mas continua rodando, porque foi escrito assim):

$ perl writeslow
hmm Input/output error at writeslow line 7.
hmm Input/output error at writeslow line 7.

portanto, o Mac OS X 10.11 (pois este hardware é muito antigo para executar o macOS) não faz nada para "tentar fazer com que os processos fechem os identificadores de arquivos abertos", conforme afirmado na pergunta, e não há evidências de "algum tipo de sinal [é enviado] aos processos que possuem esses manipuladores de arquivo" acontece; em vez disso, o processo continua em execução e, se fizer algum tipo de verificação de erro, talvez falhe, dependendo de como foi escrito.

Pelo menos para programas unix padrão que possuem o unix padrão cwde usam chamadas de E/S padrão; talvez os programas estruturados da Apple sejam de alguma forma diferentes? Vamos remontar o stick USB novamente e abrir o mlatuarquivo com Hex Fiend.app...

$ open -a Hex\ Fiend /Volumes/Firmware/mlatu
$ lsof | grep mlatu
Hex\x20Fi 66642 jhqdoe  8r  REG  1,5  216  7 /Volumes/Firmware/mlatu
$ 

(ou, em vez disso, use TextEditou algo assim, se você não tiver Hex Fiendinstalado) e mais uma vez faça a dança de ejeção de força ...

$ screencapture -w error.png
$ 

e agora recebemos uma mensagem diferente da dos programas unix padrão e nenhuma opção para forçar a desmontagem.