My responses are inline below, to the points under contention:
> - it makes object names look like links - as you note,
> "USA#Presidency_of_Adams" looks like an anchor; but it's not an anchor,
> which could be confusing, especially if the page also contains a section
> called "Presidency of Adams".

This could be bug or feature, depending on how you use it. It might be nice to
have an internal object that corresponds to an actual anchor, so clicking the
object brings you to the appropriate section.
I'd call it a bug, since my guess is that most of the time an internal object won't be in a section of its own; actually, I think the standard usage of #set_internal (or whatever it'll be called) will be on a single row defined by one instance of a multiple-instance template.

> - it's unnecessary - just adding "mainlabel=-" to the query takes care of
> the whole problem.

Internal objects can appear in many places, including query results, other
query outputs, and all browsing pages. In most cases, you cannot do complex
formatting as in #ask to get a customised display, but you need to show some
reference to the internal object -- or hide internal objects in all such
places, which would make it hard to use them. I agree that it is hard to give
names to these objects, but it seems to be even harder to generate useful
labels for them automatically. Any ideas?
Actually, given the way #set_internal works (and how I think internal objects should be queried), internal objects should only ever appear in the "main" column, not in any of the other property columns. That's because no property points to an internal object; it only points out to other values; so internal objects should only show up if they're the subject of the query. Browsing pages are an issue - I agree that the display of internal objects in Special:Browse could be nicer, but I think that's something that could be handled directly in SMW.

> - changing the direction of the property - I agree that it seems odd to
> define an object by the page's relation to it, and not the other way
> around, but (a) this is actually my preferred way of always defining
> properties - having children pointing to parents (e.g., "Is region in"
> instead of "Has region"), and (b) a property pointing from a page to an
> object would in fact never be useful in queries (it takes a little bit of
> working with internal objects to realize this.)


{{#ask: [[has presidency.start date::<1800]] }}

shows all countries who had a president before 1800. I think this is a useful
Yes, I thought about this case - the problem with this query is that it'll show each country numerous times - a country's name will appear for the number of presidents it's had before 1800. I don't believe there's any way around this, unless #ask can take in a "|distinct" parameter, like SQL has. So, given that, you could just as well call:
{{#ask:[[is president of::+]][[start date::<1800]]|mainlabel=-|? is president of}}
....and you might as well add in "|? name" in there, to show the presidents' names, so it won't look weird that country names appear multiple times.
My main points against the inverted direction are:

(1) All annotations in SMW so far work the other way around. I guess people
are used to it.
(2) For managing the data in the store, SMW currently assumes that the subject
of an annotation is the same as the page that it was stated on. Since
#set_internal would change this, it would probably require more special
handling in the store.
Well, all the other annotations in #set_internal, besides the first one, point from the internal object anyway, so I'd say the convention is being broken regardless. As is the handling; which is why SIO has its own "SQL store".

> With all that said, it would be great if SMW could handle internal objects
> directly in some way; I think of the Semantic Internal Objects extension as
> just an intermediate step toward that goal.

Well, as I already said, major parts of the required code coincide for both
approaches anyway: we need a datatype for storing the information about
internal objects and for exporting this data to RDF, and the store needs to
process this type properly. Based on this, one can either give the datatype a
parser method to read user input, making it available like all other
datatypes, or one could add new parser functions that uses this datatype
internally to store data.
Let me just note, though, that until SMW handles internal objects directly, the RDF stuff could also be solved by adding a public function and a hook to SMW's RDF handling (see the original subject of this thread :) ). That's more or less relevant, depending on how long it takes to add internal objects to SMW.