It's hard to tell for sure, given the lack of precise definition, but I
believe that the attached piece of code "should" work.  What it does is
make p1 point to c_long(20).  So ctypes should probably keep the
c_long(20) alive as long as p1 is alive (and not further modified). 
This test shows that the c_long(20) gets freed instead, making the
p1.contents reference garbage.

May I ask: do you have a real use case for this, or is it a carefully
constructed example?

Of course I take all the blame for not defining/documenting this
stuff.  My current view is this:

Python code                     C code
=======================         ================

ptr = POINTER(c_long)()         int *ptr = NULL;
x = c_long(42)                  int x = 42;

ptr.contents = x                ptr = &x;

a = ptr[0]                      int a = *ptr;
b = ptr[n]                      int b = ptr[n];

Assigning to .contents changes 'where the pointer points to'.
__setitem__ changes the pointed to memory location; __getitem__
retrieves the pointed to memory location.

Having said that, it is no longer clear to me what reading the
.contents attribute should mean.  Would making the .contents attribute
write-only help - is it impossible to construct this 'bug' without
assigning to .contents?

We're finding such bugs because we are trying to reimplement ctypes in PyPy.

I guess your last question was "is it impossible to construct this 'bug'
without *reading* .contents?".  The answer is that it doesn't change
much; you can replace all the reads from .contents with reads from [0],
and still see the issue.  See attached y.py, where I've put the
equivalent C code in comments.

Thomas, do you accept this as a bug or should the issue be closed as
invalid?

I accept this as a bug; however I don't have time now to work on it.