ChildProcess::start failing with spaces in the path

MacOSX and iOS
8

While trying to set up a minimal PIP that reproduces the error I reported in this thread Error running JUCE application with ChildProcess under Xcode Instruments profiler, I was running into the same error that was described in this thread. This PIP

/*******************************************************************************
 The block below describes the properties of this PIP. A PIP is a short snippet
 of code that can be read by the Projucer and used to generate a JUCE project.

 BEGIN_JUCE_PIP_METADATA

  name:             ChildProcessProfilerBug

  dependencies:     juce_core
  exporters:        xcode_mac

  type:             Console

 END_JUCE_PIP_METADATA

*******************************************************************************/

#pragma once


//==============================================================================
int main (int argc, char* argv[])
{

    ChildProcess childProcess;
    
    bool success = childProcess.start ("invalid_command");
    
    if (!success)
    {
        std::cerr << "No success starting child process" << std::endl;
        return 1;
    }

    std::cout << "Process output: " << childProcess.readAllProcessOutput() << std::endl;

    return 0;
}

produces the following console output:

JUCE v5.4.1
Process output: *** Leaked objects detected: 1 instance(s) of class ActiveProcess
JUCE Assertion failure in juce_LeakedObjectDetector.h:90
*** Leaked objects detected: 1 instance(s) of class ChildProcess
JUCE Assertion failure in juce_LeakedObjectDetector.h:90
*** Leaked objects detected: 1 instance(s) of class StringArray
JUCE Assertion failure in juce_LeakedObjectDetector.h:90

Program ended with exit code: 0

Please note that this is the actual content of ChildProcess::readAllProcessOutput and NOT a usual print from the leak detector.

This does not happen when passing in some very usual commands like pwd however this also happens when invoking other, normally valid commands that run successfully when calling them by hand in a terminal. Although this is not the error I encountered originally in the thread I linked above, this is a quite confusing to me right now as it opens up another error while trying to track down a different bug. Any thoughts on this?