Using a singleton class to get and set program wide settings
There should be something about a Singleton class that requires that it allow and present a single, globally available, instance.  Otherwise, the pattern is being misused.

The way your class is built, there's not really such a reason.  You could have any number of instances, and they'd all work (though they'd all look like the same instance anyway).

As for recommendations to make things less weird...?


Use instance variables.

Everything is essentially global.  (Make no mistake; hiding it in a class doesn't do much at all to change that.  static is just how a lot of OO languages spell "global".  :P)  Your "instance" is just an interface to get and set that global stuff.  Every "instance" has the same ability, since it gets and sets the same variables -- and in fact, any update through one "instance" will be reflected in every other.  So new Config and Config::getInstance() really differ only in whether another instance is created.  The caller could say one or the other, and get the exact same results.

If you insist on a singleton, moving the static variables into the instance would legitimize the existence of an instance at all, and provide a less dodgy reason to require exactly one authoritative instance.  (Though it'd also prompt the question, "Why can't i create a separate configuration for testing?".  Among others.)
Lose the public setter, or provide a way to disable it.

There's next to no encapsulation or data hiding going on here; the only thing that even remotely counts is your path stuff.  Any caller can change global settings at will.  This kind of "action at a distance" can cause all kinds of weirdness.  It is the very reason mutable global state is discouraged, and set makes it even easier to abuse.

You should consider either getting rid of the setter, making it private (and thus disabling outside modification altogteher), or adding some way for your setup code to disable it -- effectively "freezing" the instance -- once the configuration is established.
Use self::, not static::.

static (when used in place of a class name) uses PHP's "late static binding" to look up variables through the name of the called class rather than the one where the method lives.  It's there to allow subclasses to override static members.  But you've explicitly disallowed inheritance...so values will only ever be looked up in this class.  static is thus wasteful, and a bit of a mixed message.
As for the autoloader, it's not exactly a mortal sin or anything to put that in the same file as the config class.  Unless the classes are going to be moving around, though, their current location isn't really part of the config settings, is it?

I'd suggest making the autoloader a part of the startup code, unless the class files are going to move around (thus making the current location a part of the configuration).