I do not understand, what's your complain here. What is the expected behavior?

Keycodes should only be bound to one modifier, using de(neo) <LFSH> is getting mapped to both shift and lock, which is not ideal.

I'm aware of this problem but know no easy way around it.

de(neo) uses symbols/shift(both_capslock) which assigns Caps_Lock to the second level of both shift keys. In symbols/pc Caps_Lock is mapped to the Lock modifier and this ends up mapping <LFSH> to the Lock modifier which is bad because <LFSH> is already getting mapped to the Shift modifier.

Currently de(neo) uses compat/misc(assign_shift_left_action) which ensures functionality of the left shift key despite wrong modifier mapping (so there should be no functional problem here).

Ultimately the solution is to get rid of all the "modifier_map" statements and use compat-actions (as in compat/misc(assign_shift_left_action)) to set the real modifiers depending on the keysym.
As far as I know the "modifier_map" statements are kept solely for compatibility reasons.

> As far as I know the "modifier_map" statements are kept solely for
> compatibility reasons.
Yes, so the question is what would be right modifiers for Shift_L in that case? It depends on the applications using modifiers, I guess. That is why I am asking - in terms of the behavoir, is the key working correctly or not?

Currently the key is working correctly thanks to compat/misc(assign_shift_left_action).

I believe the reason for this bugreport is this error in xkbcomp:

Error:            Key <LFSH> added to map for multiple modifiers
                  Using Lock, ignoring Shift.

But the key is still working correctly because of the assigned action.

> Error:            Key <LFSH> added to map for multiple modifiers
>                   Using Lock, ignoring Shift.
> 
> But the key is still working correctly because of the assigned action.
I do not even see that error (Fedora 19):

setxkbmap -layout de -variant neo -option '' -print | xkbcomp - -xkb out.xkb 2>&1 | grep LFSH

Try executing these two commands:

    setxkbmap de neo -print -option | xkbcomp - -xkb out.xkb
    xkbcomp out.xkb -xkb out2.xkb

xkbcomp doesn't report an error on the first run, because the modifier_map statements look like this (xkbcomp doesn't check if two different keysyms resolve to the same key):

    modifier_map Shift { Shift_L };
    modifier_map Lock { Caps_Lock };

after the keysym has been resolved to a key, they look like this in out.xkb:

    modifier_map Shift { <LFSH> };
    modifier_map Lock { <LFSH> };

So the error occurs on the second run of xkbcomp. 
As the error reports, the Shift modifier is getting ignored, so in out2.xkb there is just

    modifier_map Lock { <LFSH> };

Can this be fixed please? I'm running into trouble like you see in [1]. I don't really understand the internals, but caps lock in Neo2 is Shift_L + Shift_R and not just Shift_L. Maybe this is resolved in Neo2 meanwhile?

[1] https://github.com/xkbcommon/libxkbcommon/issues/44#issuecomment-285277028

> I don't really understand the internals, but caps lock in Neo2 is Shift_L + Shift_R and not just Shift_L.

You can find the definition of the neo layout in the file /usr/share/X11/xkb/symbols/de, where it says "neo_base" and "neo". You will notice that "neo" contains this line:

    include "shift(both_capslock)"

which explicitly implements the behavior of Shift_L + Shift_R => Lock. So this is not a bug, it's a feature.