1) it is because it is a pointer to a cursor, and a pointer that could point to many different cursors over time.
for example:
if ( x = 1 ) then open c for select * from dual;
else open c for select * from all_users;
If we 'cached' C open the first time around, it would tend to point to the same query every time, even if (x=1) changes its boolean result.
Additionally, you could have a function:
create function foo return sys_refcursor
as
l_c sys_refcursor;
begin
open l_c for select * from t;
return l_c;
end;
and one could call foo like this:
begin
l_cursor1 := foo;
l_cursor2 := foo;
end;
If foo cached l_c, there would be one occurrence - in general there needs to be "many" and each one in turn would point to a completely different result set. So, in short, a ref cursor is just a pointer to some arbitrary (not really arbitrary, you choose) query. It many have multiple open occurrences and each may be a completely different query.
2) you would have to define "truly open cursors". I define that as (a) and (b). That is what v$open_cursor in general will show you.
3) the plsql cursor cache works for the client mostly. Say you have open cursors set to 100. and suppose you have session cached cursors set to 50. So, plsql will cache up to 50 open cursors for you in plsql.
Now, suppose your client application has 50 cursors open and plsql has cached 50 cursors as well. You now have 100 cursors open. If your client code attempts to open one more cursor - what will happen?
what happens is that plsql will silently close one of its cursors so that you may open yours. Your client will have 51 cursors open and plsql will have 49. Plsql will keep doing that until your client has 100 cursors open (and plsql will have none) before you receive an error regarding max open cursors exceeded.
the sql area representation of what plsql points to is subject to flushing just as any open cursor is. For example, if plsql has a query "select * from t" open AND you create a new index on T, the sql for T will be invalidated in the cache - and plsql will implicitly cause that sql to be recompiled again if and when you execute it.
4) the quote in question is here:
http://docs.oracle.com/cd/E11882_01/appdev.112/e10472/static.htm#LNPLS00602 it is better to read in context, it makes more sense in context. They are calling PLSQL cursors 'session cursors', it is the plsql managed bit they are referring to. PLSQL is a layer, a programming layer and it manages its own cache of cursors.
The client code would have its concept of a session cursor as well - if you open a cursor in the client, it really just points to a cursor area in the SGA/PGA on the server side. PLSQL is the client in this cases.
5) no, it would raise that error when your client attempts to open more than open_cursors number of cursors (see #3 above)
I did not understand your last paragraph - you would need to restate that somehow.