I tried on Intel HD4000. It seems to me that something happened with Material Node. I just tried to mute ("M") material node and saw rght result. Even if you remove all the nodes except the Output, and Material, all particles are black. Will try it tomorrow with nvidia.

Confirm bug on nvidia, but the behavior different from what observed on intel HD4000.

Tested on Ubuntu 14.04

NVIDIA BI - 0
NVIDIA Viewport(GLSL) - 1
Intel Hd4000 BI - 1
Intel Hd4000 Viewport(GLSL) - 0

0 - ok, 1 - bad

Hi Alexander,
for me it's always "bad" - no matter if the viewport is rendering the scene or the rendering has been started via F12. Even if I delete the material node and only use a color ramp plugged directly into the output, the behaviour persists...

There is no lamp in .blend.
But a shadeless material is showiing something into 3D view with a material display.
It should be the same for render. But render stays black.

It looks like without nodes. Dupli option for mapping from parent is still working.
So, inability to render particles into different colors seems to be specific to the node.

@ronan ducluzeau (zeauro) Ronan, there does not need to be a lamp - the world is using "ambient occlusion" with "Add" - so that's our lamp.

This issue partially related to fix for T46194. Git bisect led me to it. Fix for T46194 breaks BI render when use no Material node (linking directly to Output node). There was crash when obi->index was greater then psys->totpart. This condition means that the child particles are used. But psys->child is NULL. @Campbell Barton (campbellbarton) could you help?

Well, you can't see anything in Material Viewport shading without an illumination from lamp or material.

@ronan ducluzeau (zeauro), Please, this is no forum, we try to locate the bug here... your posts don't help in processing the bug and are irrelevant for actual problem. We're rendering here and are not previewing anything.
@Alexander Romanov (a.romanov) Let's wait for @Campbell Barton (campbellbarton) then...

Here is the patch that fixes BI when using Output node without Material node. It also prevents the crashes mentioned in T46194.
But it has the exceptional case which is not clear to me. if (psys->child)....

@thomas (thomas) Beck. My comment was relevant.
Particle node is new for BI and BGE. Knowing that it is working for viewport and not render is a different info that a node which does not work at all.

In T46333#338839, @Alexander Romanov (a.romanov) wrote:

Here is the patch that fixes BI when using Output node without Material node. It also prevents the crashes mentioned in T46194.
But it has the exceptional case which is not clear to me. if (psys->child)....

fix_T46194.patch1 KBDownload

With the Material node the patch works too (checked on NVIDIA)

Hi Alex, just checked the file on my machine with your patch. Everything seems to work fine.

Checked the patch and it restores old behavior and doesn't crash with T46194
but there are some confusing things going on here.

• ObjectInstanceRen.psysindex starts at 1, where 0 means there is no particle system. So changing the code to start looking at 0 just makes duplis (any non particle duplicator) pick the first particle system.
• if (obi->psysindex >= 0) { is a redundant nop check, normally harmless - but in this case misleading since it hints that -1 is used, when its not.
• RE_addRenderInstance's psysindex arg, is an index from obi->ob->particlesystem, used to access a different list (obi->par->particlesystem).

From what I can tell this is working by accident, all duplis just pick the first particle system.

@Alexander Romanov (a.romanov) / @Antonis Ryakiotakis (psy-fi), is this whats expected or am I missing something?

Note, a slightly modified fix with comments to avoid future confusion:

it seems I was wrong in my understanding. I attach аnother patch where the particle system is taken from the DupliObject. Now multiple particle systems works for me. Check, please.
[EDITED] Patch updated:

@Alexander Romanov (a.romanov), thanks for investigating and finding the correct solution. Tested and works well here, on this report and T46194.