This is a PR which merged about two and a half years ago.
Recently, there have been some discussions there, now move to forum.
For major feature like this, it would be better to discuss together in community, to avoid make decisions that users do not expect.
Thanks.
I introduce a question here too.
If fork is not necessary for start a background daemon as replied in original PR, can i know how to do Process.daemon in ruby for crystal? we know exec is a way to transform the current process into another one, how to do the fork + exec in Crystal?
That can be done with Process.run.
The standard way to run background daemons on Linux nowadays is not to initiate it via forking, but to start it in a blocking manner and leverage the system to handle things (ie service files with type=simple for systemd).
So do you want an actual daemon or do you just want to run am arbitrary program in a separate OS process? There are several different replacements to fork and which is reasonable for you depend on what you actually try to achieve.
In fact, i am porting a ruby gem which is a process manager which support start others process as daemon, yes, it actually provide features like systemd, support both run processes in foreground or background.
Out of curiosity: why are you porting that gem?
In fact, porting was stopped recent days because others things, but i will continue on it next several days. 
Out of curiosity: why are you porting that gem?
Because i used it for my personal site deployment, deploy use it quite comfortable for me, I donât have to have to add system/user systemd service for this, i use it on my development enviroment too.
Sure I can install the ruby version use distro package manager, but, that pull many ruby dependencies, everyone love one-binary nowadays.
Another answer, shouldnât we be actively porting useful Ruby gems to Crystal? did you implicitly say that the Crystal language was not developed for such tools?
No, I was just curious about the use case. Some people port code just because they love porting things, not because they use it. This wasnât the case 
do we have precedent for other common used general purpose languages?
Rust doesnât have fork
BTW, Rust no builtin support for fork, need use nix crate, But, Rust doesnât have builtin async solution too, AFAIK, there are so many crates(futures, smol, tokio) for this, Crystal also excluding fork, does it mean that spawn + channel will also be removed from the standard library in the future?
I would also remove Process.fork because it caused me a lot of trouble when trying to refactor some things related to libevent. The main problem is that it doesnât stop all fibers except the one calling Process.fork.
E.g. for pthreads, only the calling thread survives the fork system call. A similar solution should be implemented for Process.fork and fibers if it remains accessible from outside.