Pretty much any problem you can think of, the sadists/masochists over at Boost will have came up with a "solution" for it. Alternatively, named parameter idiom always "works" too.

I didn't get it.

You know, that's true. I haven't used a good one in a long time and I forgot that side of it. One of the reasons I use Geany is that it's very fast and responsive, but perhaps I should look into a more exhaustive IDE.

That point aside, Pass by Name is still a very useful feature. So much so that in, say, Verilog, it's the proper way to do parameter passing.

Name parameter allows for optional parameters without having a bunch of overloads that C++ has (and they actually allow for more combinations than overloads allow actually)

In practice, I'd say that named parameters are only relevant for extremely stable APIs, and in that case you will probably memorize the API and not need something like this. In cases where there are several optional parameters then I guess it could be useful. Often this is accomplished in dynamically-typed languages that support it with an objects' properties. The same thing can be accomplished in statically-typed languages, though it comes at the expense of having to know the parameter types. And if the option/parameter names ever change then it can domino into a lot of maintenance. I would generally avoid abusing this. Most of the time, filling in nothing/null/zero for optional parameters that you don't need should suffice well enough. If you find that your API is too complex or too much work with this then perhaps you need to rethink your API. You can always offer alternative overloads, or factories, etc.

Perhaps, but in a language that is known for relative speed this level of dynamic magic comes at a significant cost. It basically forces you to assess why you're using a static language at all if what you really want is dynamic. Proper dynamic languages do it much simpler and will be much less error-prone. They can also generally be bound closely to the metal with some C glue where appropriate.

As a rule, I'd say that if your constructor/initializer (or any "subroutine" in the general sense) has an unreasonable number of parameters then it's probably also a sign that you're doing it wrong and that your "thing" has too much responsibility. Also keep in mind that a "factory" object is a good solution for centralizing the simplification of a mess for you. It lets you put it in one place, and reap the benefits of a simplified interface, without negatively affecting the design of the "real" thing.

I encourage you to experiment anyway because that's the only way that you'll be able to assess their fitness for a particular purpose. That said, if what you want is something more dynamic then consider a dynamically-typed language. I think it's pretty well established these days that Real(tm) programmers use the best tool for the job, and that even "scripting" languages are programming languages.

spawn(0,0) :
   velocity(2.5, 2.5),
   direction(DIR_NORTH),
   ID(10015)

Problem is that parameter names in function declarations are completely superfluous in C/C++. It's completely valid to declare the same function multiple times, each with different parameter names. You don't even need to give a name to a parameter in a declaration (or definition in C++, if you don't use the parameter).

As for your example, I think the "proper" C++ way would be something like:
object.spawn(0,0).velocity(2.5, 2.5).direction(DIR_NORTH).ID(10015);
Each member function would return a reference to (or copy of) itself, which allows you to call another setter, etc, and get the resulting object.

object.spawn(0,0).velocity(2.5, 2.5).direction(DIR_NORTH).ID(10015);

While this is nice, these are just setters and they leave the object incompletely initialized until every setter is used. It's just a trick. You need to use a constructor, because they allow both for member initialization, and parameters as well.