Some of the documentation points towards the requirement of a placement dealocator for every placement allocator that is defined. This dealocator is called if the placement allocator fails, automatically by the compiler. It is only explicitly called anywhere else, with special syntax. This is where MSVC2015 failed to compile because the placement allocator used for the proceeding array needed a placement dealocator which matched (was too similar to) the declaration of the sized dealocator.
In the C++11 draft (the final versions must be bought), I fond the following quote regarding exception handling during initialization or the allocated object(s): "If the object was allocated in a new-expression, the matching deallocation function (3.7.4.2, 5.3.4, 12.5), if any, is called to free the storage occupied by the object." Note the "if any". I can't find anything stating that they must come in pairs, but it is hard to search for if you don't know the terminology they would use to describe it. Some examples with class specific allocators or deallocators also feature only one of them. The C++14 draft contains a similar quote. There it is followed by a note that not having one is for when no memory was allocated (dynamically I assume) by the matching allocation function. If it was, you will leak memory if the constructor fails. (The final version of the standard costs money, while the older ones are withdrawn.)
Simutrans does allocate memory, but these classes don't have constructors that can fail (that I am aware of at least), so there is no case where these matching deallocation functions would be called anyway. Delete operators will call only the single-arg or sized deallocation function (operator delete) irrespective of how new was called (in general, it can't know), but we do not delete besch classes either that I am aware of. If we do, I think it will use the global deallocation functions in the absence of class-specific ones.
Not to interrupt your discussion, but is there any suggestion on how to make the code standard conforming?
As far as I can tell, this particular part of the code is. One might try to declare a single-argument (just the pointer) deallocation function (operator delete) in obj_besch_t to see if that unconfuses the compiler.