I'n not sure how to think about the procedural API as how does this look like compared to an object oriented one?
I'm assuming that the procedural API is more for the benefit of providing a usable public interface in other languages, rather than the final interface. It could become a hassle to keep track of the many different global functions, especially since OOP provides some organization in a way, but I suppose what you could hope for is that the BMax wrapper of the engine, and perhaps the C++ interface itself, will have their own wrappers around the procedural API.I'm not enthusiastic about the way this is being handled, but then I really don't know that much about how it's being done in the first place. I'd say it's best to wait and see in this case. It may be that coding will simply be better with the straight procedural interface if B3D's is anything to go by (which was completely procedural and still very easy to use). That's not to say I'd go back to using that sort of interface- Truevision 3D spoiled me quite a bit.
(Not talking to taumel now)
On the topic of formats/tools, I'm going with Mark on this one, although perhaps for slightly different reasons. The problem is that no one tool is going to meet your needs. This is an unfortunate part of game development and I think some of you haven't quite realized this yet because you're too busy complaining about the decisions Mark makes. Rather than try to make the be-all-end-all tool and end up with some gigantic, horrible behemoth (FBX and Collada are great examples of standardized formats backfiring so hard that they splattered everyone with blood and bits of poo) that never really does what you want. Write your own tools, come up with what you want in the tool, and stop complaining about how you won't get the wonderful tools you're imagining (because you won't, and that's not going to change unless you do it yourself). If you really can't handle that, do you think you're in any position to be making games?