Depends on the implementation, I guess. Just write a simple test case and try it. In case of doubt, I would go with a bitwise or hex representation of the number instead like 0b11111111111.... or 0xfffffff... if that's supported by C#.

No, Hashtable and HashMap don't care about this. And why would they? I consider it to be rather...not stupid...but, well let's go with stupid anyway...behaviour to throw an exception in this case. You would have to modify the code to check for the key and remove/add it or replace it, if that's supported.

That's default behaviour, because it's usually the fastest way to do it (apart from compiling objects). You can disable it by setting:

Config.glVertexArrays=false;

Have you tried something simple, like a box or a sphere? Do those render correctly?

I don't know how much you've changed (obviously something, because otherwise, there would be no need to call init() by hand), so it's really hard to tell.

This line:

Expanding command queue to 3000 entries!
Indicates that your port never flushes the command queue, which usually happens, if no actual rendering happens for some reason. The queue fills with render commands, usually until you invoke the display() method AND your display implementation actually gets called (with normal LWJGL and software renderer, this happens instanstantly). With AWTGL and JOGL, it happens when the next iteration of the UI thread happens. I've no idea how C# handles this, though.
Anyway, if the queue never gets flushed, buffered commands will pile up like you see in this log output.

I'm not quite sure what you mean. There is no such method in thre AWTGLRenderer itself. There is one GLBase though (which is extended by AWTGLRenderer) and that one is being called by init() in AWTGLRenderer.

...finally. Please let me know, if there are any problems with this change.

You can assign the texture with the rendered depth buffer to another object and do something with it in the shader. That said, jPCT's shadow mapper doesn't do this but it's encoding the depth values in the actual pixel data for reasons that I can't remember anymore. Some compatibility issues, I guess...