The coreutils 8.28 release, when built on macOS 10.13 under the new APFS filesystem, produces a hang during the test suite run. The hang appears to occur in the execution of coreutils-8.28/tests/split/filter.sh at..

+ yes
+ head -n200K
+ split -b1G '--filter=head -c1 >/dev/null'
+ for mode in ''\'''\''' ''\''r/'\'''
+ FILE = -

according to the filter.log generated from executing the section of
split/filter.sh containing...

yes | head -n200K | split -b1G --filter='head -c1 >/dev/null' || fail=1

# Ensure that "endless" input is ignored when all filters finish
for mode in '' 'r/'; do
  FILE = '-'
  if test "$mode" = ''; then
    FILE = 'zero.in'
    truncate -s10T "$FILE" || continue
  fi
  for N in 1 2; do
    rm -f x??.n || framework_failure_
    timeout 10 sh -c \
      "yes | split --filter='head -c1 >\$FILE.n' -n $mode$N $FILE" || fail=1
    # Also ensure we get appropriate output from each filter
    seq 1 $N | tr '0-9' 1 > stat.exp
    stat -c%s x??.n > stat.out || framework_failure_
    compare stat.exp stat.out || fail=1
  done
done

I haven't opened a radar report yet as the Apple engineers can't look directly at the source code for coreutils due to the GPLv3 licensing and the test suite seems to be tangled up with the makefiles making it impossible to extract a stand-alone test case reproducer to attach to a radar bug report.
      Jack
ps Again, the hang seems to occur at the tail end of the log after it emits...

+ FILE = -

Any suggestions on how reduce this to a simpler test case? I would note that the new APFS filesystem produces a failure in the python test suite...

https://bugs.python.org/issue31380

which is due to APFS not allowing files to be created with filenames that contain unassigned codepoints in the Unicode 9.0 standard, whereas HFS+ does. So perhaps the coreutils hang might be a similar issue?