Seems I got it working pretty good:

    // Addition by NicoHood
    template <typename First, typename Second, typename Third, typename... Rest> 
    inline size_t print(const First& first, const Second& second, const Third& third, const Rest&... rest) {
        // A Wrapper is needed here in order to not call the
        // Formatted functions if the input was three integers
        // If you input only two integers the formatted
        // Functions have higher priority
        return printWrapper(first, second, third, rest...);
    }

    template <typename First> 
    inline size_t printWrapper(const First& first) {
        return print(first);
    }

    template <typename First, typename... Rest> 
    inline size_t printWrapper(const First& first, const Rest&... rest) {
        size_t r = 0;
        r+=print(first);
        r+=printWrapper(rest...); // recursive call using pack expansion syntax
        return r;
    }

    template <typename First, typename Second, typename Third, typename... Rest> 
    inline size_t println(const First& first, const Second& second, const Third& third, const Rest&... rest) {
        // A Wrapper is needed here in order to not call the
        // Formatted functions if the input was three integers
        // If you input only two integers the formatted
        // Functions have higher priority
        return printlnWrapper(first, second, third, rest...);
    }

    template <typename First> 
    inline size_t printlnWrapper(const First& first) {
        return println(first);
    }

    template <typename First, typename... Rest> 
    inline size_t printlnWrapper(const First& first, const Rest&... rest) {
        size_t r = 0;
        r+=print(first);
        r+=printlnWrapper(rest...); // recursive call using pack expansion syntax
        return r;
    }

Code to test:

  Serial.println("1",  "2", 6, "3"," Word " , "4", '!', "5");
  Serial.println();
  Serial.println(44, 44, 44);
  Serial.println();
  Serial.println(44, HEX);
  Serial.println();

// this produces the same flash size:
  // Serial.println("1", "2", "3", "4", "5");
  Serial.println("1");
  Serial.println("2");
  Serial.println("3");
  Serial.println("4");
  Serial.println("5");

Edit: One could also adapt this to other functions like:
pinMode(2,6,3,9,INPUT);

Edit2: Just a thought: Maybe we can also change the DEC, HEX, BIN into an enum and then be able to print 2 integers and a formatted integer at the same time. Maybe, not tested.

At first glance, this seems like a great addition and I'm sure there are some further improvements we can look at. However this code will cause the current API to become C++11 only. Even if the code is wrapped in define guards, the reference will become separated unless a C++98 compatible version is provided using variadic functions.

I do have an idea though! I give it a test when I'm home in a few hours.

Ooh, yeahh!! +1!!

For some reason the print (without ln) has no higher priority on 1-2 function parameters. Meaning it will result in a loop and don't print anything. That is not a problem though, we can force the function to take at least 3 arguments to it wont bother at all. So if you input more than 2 args (>=3) it will print them in a row. No matter what type it is (int, float, String, char).

Formatted printing will not work I think.

I updated the code above. Should I create a PR to test this code?

Edit: @Chris--A Since we now have c++11, why not use it? I see no problem with that. Its enabled anyways.

With the current pinMode layout it does not work with some overhead. At least I wasnt able to make it smaller. The problem is that the last argument is important for the other inputs. Here is a working, but more expensive example:

#include "Arduino.h"

// Addition by NicoHood
template <typename First, typename Second>
inline uint8_t pinModeWrapper(const First& first, const Second& second) {
  pinModeWrapper(first, second);
  return second;
}

template <typename First, typename... Rest>
inline uint8_t pinModeWrapper(const First& first, const Rest&... rest) {
  uint8_t mode = pinModeWrapper(rest...);
  pinModeWrapper(first, mode);
  return mode;
}

template <typename First, typename Second, typename Third, typename... Rest>
inline void pinMode(const First& first, const Second& second, const Third& third, const Rest&... rest) {
  uint8_t mode = pinModeWrapper(second, third, rest...);
  pinMode(first, mode);
}

I agree it should be used, however as it hasn't been released yet (an IDE with C++11 enabled) making the API version incompatible is quite restrictive. This should be discussed first I think (with the users, not dev team).

Many people chose to use the older IDE when breaking changes for IDE 1.0 were released, and subsequently many libraries written after 1.0 contained checks for WProgram.h to cater for the many people that used out dated third-party forks, or simply didn't want to upgrade.

Adding in this breaking change will prevent people from testing libraries/code for the older IDE's (by only a few months) and give many people further reason to not upgrade. As this code is just a convenience and doesn't allow a result that wasn't already possible, careful consideration should be put into this addition.

Hum? C++11 is in the current 1.6.6 release merged.

This is a minor feature, nothing so much new. Its just a nice addition for the 1.6.x branch. Doesnt mean you cannot stick to the old version. And that there is a gap between 1.0.x and 1.6.x we already know and it will grow from update to update. That is progress in development. And this tiny addition shouldnt keep us from adding it.

They changed the whole USB core and I think this wasnt backported to 1.0.x, if they ever release 1.0.7. So the whole USB code will be more or less incompatible without some fixes. So I dont get the problem of adding this.

The current release tag is 1.6.5, 1.6.6 hasn't been released. As minor as it is, if I enable gnu++98, the API no longer is compatible. It doesn't mean you can't use it, it means you cannot even compile the code.

At the very minimum, like the other C++11 code already implemented in the API, it should be disabled for C++98.

It should also be noted that many people can't use the latest releases due to their OS or other restrictions not supporting it (Mac has a minimum version now if I recall).

But either way, the code will eventually have to look at moving forward and forgetting the past, it just needs to be done carefully.

I am working with the nightly build. And this has c++11 and 1.6.6 will also have c++11

Yes, however this is not the point I'm arguing.

no idea if this helps, but:
for adding (concatenating) ANSI strings I'm using my own stradd() funktion:

char * stradd(char * s, int n, ...)  // "adds strings" s=sumstring , n=number_in_list, ... = var string list
{
    va_list vlst;   
    int i;

    char * bufptr;
    char * retptr = s;

    va_start(vlst, n);
    for (i=1; i<=n; ++i)   {
       bufptr = va_arg(vlst, char *);
       strcat(s, bufptr);
    }
    va_end(vlst);   
    return retptr;   
}

Having this, you can concat a variable number of strings (tokens) to 1 long string and then do with the complete resulting string whatever you want.

OT:
the editor for posting (e.g., source code) is really a crap!

@Chris--A, wrapping these methods in proper #ifdefs would solve the "it doesn't compile", I guess. But I'm not sure why this would be needed? Is there any good reason to disable C++11 mode for the Arduino core? There are probably other compiler flags that, if you change them, will break the compilation?

Another point that has not been mentioned is conflicts with the current print() methods. In particular the integer and float printing versions:

 Serial.print(100, 16);

Should this print "10016", or "64"?

It seems the conflict is minor, but I'm not sure which version will be favored by the compiler, and it is fundamental - if you have an any-number-of-arguments version, you can't really use extra arguments for specifying the formats.

the editor for posting (e.g., source code) is really a crap!

It helps if you use markdown for your code blocks. I added ``` around it to make it a proper code block now.

The current template above only works for >=3 parameters and wont do integer formating.
Meaning print(100, 16, 42); will give "1001642"

Otherwise we'd have to use enums for the HEX and DEC definitions and exclude the enums in the template (and I dont know how to do that or if its possible). Thatswhy the function is kept for >=3 args which should not conflict.

I'm afraid that if print("Hello", " ", "World") works, but print("Hello", "World") does not, people will be terribly confused and this feature hurts more than it helps.

Using enums for HEX etc. could help, but that won't help for the print(float, precision) version, where the precision is specified as a plain int instead of a constant...