The default config (version 6.0.18) contains the following lines when an instance is first launched on a Windows machine:

S:blueprints.libraryInput <
        "$MINECRAFT\blueprints"
        "$MINECRAFT\config\buildcraft\blueprints\client"
        "$HOME\Downloads"
     >
    S:blueprints.libraryOutput="$MINECRAFT\blueprints"
    S:blueprints.serverDir="$MINECRAFT\config\buildcraft\blueprints\server"

These use Windows-style "" characters for the folder paths. In an OSX/Linux environment, a similar config is generated with "/" as the folder separator. However, when a Windows instance is copied to an OSX/Linux machine (as in the case of a modpack distributed through the ATLauncher), this results in the creation of a folders titled ".\config\buildcraft\blueprints\server" and similar in the Minecraft directory. (This is the actual name of the folder, NOT a path.)

Perhaps these paths could somehow be made platform-independent, even after the first generation of the configuration file.

(This behavior first noticed with Beyond Reality 2.1.6 from the ATLauncher.)

Have you tried with an up-to-date Buildcraft version? Have you checked your main.conf to make sure that the path in there is correct?
This was supposed to be fixed some time ago (see #2021, #1975)

@mdfntr - Oh! I see what I have to do now! This is a valid bug.

I have not tried a more up-to-date version of Buildcraft, and I will try that sometime tomorrow. However, I think that the problem I am having is different from the ones referenced in #2021 and #1975. In my case, the configuration is already generated, presumably on the pack-maker's Windows computer. I then launch the pack on my OSX or Linux computer which creates the strange folders (as it should, according to the config). When starting up a virgin instance with Buildcraft on my OSX computer, the folders are created as they should be.

These are two different situations--what I guess I am asking for is some logic to switch between "/" and "" depending on the environment that is currently running, even after config generation. Or perhaps some other way to make the folder path separators in the config file system-independent.