Actually, those two Domain Aggregate functions make perfect sense - if you realize that they work on queries that have ORDER BY clauses. DFirst and DLast in an ordered recordset will work exactly as you would think they do. It is only for tables that they don't work as you might have hoped. But in fact, it isn't the fault of DFirst and DLast - it is the fault of the tables.
Here is the mechanism. Imagine that you have a sorted Excel data set that you import into Access and load it for the first time. OK, after that import, the new table should be sorted the same way as it appeared in Excel. But now let's update some records chosen at random. What is ACTUALLY stored in a table is a set of records. It is not clear as to the actual method of storage because Microsoft has not published Access Internals that often, but I personally believe that each table is actually a double-ended queue. The ".MoveNext" and ".MoveLast" operations would be most easily supported by such a structure. (I know that's not proof - it's just a suggestion based on my inference.)
Let's say you now update several records, almost at random. If you use the db.Execute query, dbFailOnError and an error occurs, you have to be able to roll back everything. So because of the need for the ability to be able to roll back changes, Access CANNOT just modify the records in place. It must COPY each record in turn, update it, and finally attempt to thread everything back into the table. The easiest way to do that is to thread it into the end of the table rather than trying to find fore-and-aft linkages to other records. Things will be threaded back in the chronological order in which they were modified - which leads to pseudo-randomization. (Remember, we said "update almost at random.")
Why put them at the end? (You ask....) Because tables are defined as UNORDERED recordsets. So it doesn't MATTER to the definition of the table that you don't maintain the original order. So it is trivially easy to append the changed record to the end of the double-ended list that is the physical table. The only tricky part is removing the old record from the list - which is not hard for a double-ended list structure. But in any case, after you do this often enough, you would realize that the actual order of records in a table is ascending chronological order of creation or update. Why WERE the records in order when you first created the table? Because that was also the chronological order of presentation - because in my set-up, I said it was a sorted Excel datasheet.
Now, let's ask the question: Do DFirst and DLast do anything unexpected? No, they just open the indicated recordset and do a .MoveFirst or a .MoveLast on it, pick up the requested field, and close the recordset, exactly like you might expect. What they GET depends on the recordset they opened, and as we all know, both tables and SELECT queries produce recordsets equally well. But only one of those two sources is guaranteed to be in a particular order.