Basically, it comes down to this question: Why should a game developer use our library rather than another?
SDL, for example, is a very low-level system. It is, effectively, DirectX ported to many platforms, along with some other useful functionality to make cross-platform. While a game developer can certainly use it, there are problems to being this low level. It simply doesn't abstract the hardware enough.
If you were to try to make an OpenGL driver for SDL, you would have some problems. Chief among them would be that SDL doesn't allow for the richness that OpenGL could provide for 2D blitting. Fast rotation and scaling (virtually the same speed as not having them), fast blending, versatile blending, access to basic per-fragment operations, these would all require entirely new API functions. As such, SDL is not designed with such features in mind.
Once you have such an API, though, the question becomes how to know about when you can use it and when you can't. Also, how does one gain access to this kind of functionality?
AllegroPro will provide that way. SDL is designed to abstract hardware. AllegroPro is designed to make games. This puts it at the level that is most convenient for game developers, not at the level where hardware ends and the user code begins. One should use AllegroPro over other libraries because it permits them to focus more on the game itself rather than dealing with hardware issues.
Technically, the AllegroPro design does not call for the use of any existing Allegro 4 code; it is a total rewrite of the library.
Allegro 4 is not well structured to what AllegroPro needs to do. In particular, it makes it difficult to access hardware in a specific way. It has a lot of poorly-thought out designs for concepts like blending. As such, the majority of the code would have to be stripped or removed anyway. So there is little point to starting with a codebase that will have to be mostly rebuilt.
Also, old code can have hidden pitfalls. We want to build a stable system here. And, since we're breaking backwards compatibility anyway, code reuse is not the most important thing right now.
Additionally, Allegro 4's internals are not documented at all. Since few if any of the Allegro 4 developers are involved with AllegroPro, few of the Pro developers have an intimate knowledge of Allegro 4's internals. It would be easier for them to just rewrite it and be done with it.
Lastly, AllegroPro can still use some Allegro 4 code internally. It's software bitmaps could be used as the basis for the generic graphics driver. So some Allegro 4 code can still live on inside AllegroPro. Also, the AllegroPro Development Roadmap document specifies that initial drivers will use Allegro 4 as their basis. This is to get the system up and running as fast as possible. A functioning system is easier to develop for than a non-functioning system.
Technically, nothing is said one way or another about DOS support. However, DOS is not a multithreaded system, and since threads are likely to be used by sound drivers, that's 2 systems gone.
Primarily, given a total rewrite of the code, supporting a system that is so fundamentally different from any other system, like DOS is, is just not that useful. Also, DOS is a very old system; few people use it. The vast majority of OS's are Win98 or better, Linux, or MacOS.
One of the biggest changes between Allegro 4 and AllegroPro, in terms of non-driver features, is the explicit exposing of the driver model to the user. There are a number of reasons for directly exposing this model to the user.
First, it allows the user to create 2 or more drivers for a particular component. For example, if the user is creating a tool, the user might have the main window use an OpenGL driver. However, GL drivers tend to be fairly resource-intensive. Such drivers are not necessary for other tool-bar windows. As such, those could use GDI drivers, which require far fewer resources.
Second, it makes it much more explicit what is coming from hardware and what is software. The Allegro 4 function, "create_bitmap" creates a memory bitmap. However, this is an act that AllegroPro should discourage; the equivalent correct Allegro 4 function to call would be "create_video_bitmap". AllegroPro should encourage the use of hardware resources rather than software. As such, it is important to make the use of software resources as explicit as possible. Forcing software modes onto a driver, thus providing a different interface, is a way to handle that.
The predominant objection to this model is that it complicates code. To some degree, this is true. However, most of the API will be operating on objects produced by drivers. These objects have intrinsic knowledge of their driver, so most of the API will not need to be told which driver to use in the operation. As such, only a relatively small portion of the API will be affected.
The removal of packfiles and datafiles was done to separate the API into a clean base upon which various layers can be added. However, the removal of such useful functions like "load_bitmap" was done for other reasons as well.
One problem with "load_bitmap" and their ilk is the inability for these functions to be useful in production games. Functions like "load_bitmap" are useful for loading data in a prototype application, but for actual game production work, one tends to be working with data stored not in .bmp or .png files, but as memory images stored in system memory (initially after loading). It would require a system similar to Allegro 4 packfile system to load large blocks of binary data and convert them into appropriate driver-based data.
Such functions can easily be added as a layered API, though simple file access mechanisms. Since they need not have intimate knowledge of the driver, they do not need to be part of the AllegroPro core.
Fixed-point math is useful on older processors. It does have a few advantages over floating-point, but a very few. Also, fixed-point math is looked by many on as a somewhat old-fashioned feature, not useful in modern API's. Regardless of the veracity of this statement, to keep said functionality in AllegroPro could create a source of derision for the library.
Plus, floating-point math is what CPU makers are concerned about optimizing these days.
Software 2D rendering has its place; occasionally, you have an effect that can only be done by getting at the bits on a CPU (though modern 3D shaders can do virtually anything you can on a CPU). However, the days of software 3D rendering are quite dead. The primary reason to do software 2D is to provide features that you cannot get in hardware. Any feature that modern hardware 3D API's cannot achieve will never be practical on software 3D. As such, there is no need for software 3D.
As for the 3D math API, there is something to be said for having a vector math library, even on a system that will be predominantly used for 2D rendering. However, such a thing has little to nothing to do with the core itself. So, that can be left as a layer onto the core.
Having a GUI in a low-level game programming API is not a good idea. AllegroPro should be a base for such things; they do not need to be fully integrated into the core system.
You've got threads now. Also, you can access a high-fidelity time counter, so actual timer objects are pretty irrelevant.
Multithreading is a feature that is added more for the benefit of actual drivers than for the user. Multithreading a game is typically not an advisable act; unless one has multiple processors, this is will decrease performance in most cases.
However, there are some cases where multithreading is useful. Take asynchronous file IO, for example. While one could expose the hardware's async capabilities via an API, these are usually based on esoteric features of the harddrive itself, like sector size, etc. Files would have to be built around these limitations, and these limits are all platform specific. As such, the platform neutral way to perform asynchronous file IO is to just load it in another thread that can freely block. Audio can freely run in a separate thread as well, as can the input buffering routines.
Of course, once the decision is made that internal AllegroPro drivers need threading, the question becomes why not to expose these to the user?
The biggest reason to not provide for multiple threads was support operating systems that don't provide thread support. All modern OS's do now, so this argument holds no weight.
Another, much weaker, reason for not exposing them is that it is very easy to see threads as the solution to all of life's problems and overuse them. However, the fact that an feature can be used pathologically is not sufficient reason to disallow the existence of that feature.