I've found a way to use the default exit functionality simultaneously with exit objects. Don't know if anyone is interested, but I though I'd share it anyhow. What follows allows you to devise exits in three ways. You can:

1) Write an exit script with default syntax. This takes the highest priority.

define room <Cabin>

    north {
        'script
    }
    ...
    
end define

2) Define an exit object for a particular direction, which will be used if you've not written a script for that direction as described immediately above. The name of the exit object should be an amalgam of the room name and the direction that it controls.

define room <Cabin>

    ...
    define object <Cabin_North>
    
        ...
        
    end define
    
end define

3) Use the default exit syntax as a property. This is the lowest priority - if you've not written a script for the direction as described in step 1, nor defined an exit object as shown in step 2, then the room specified by the exit property will be used.

define room <Cabin>

    north <OutsideCabin>
    ...    
    
end define

So here's how you do it:

A) Write directional commands that call the direction action of a room. For example:

define game <SomeGame>

    command <north; n> {
        doaction <#quest.currentroom#; north>
    }
    
end define

B) In the defaultroom type, add all the directions as actions. These actions call a 'travel' procedure. For example:

define type <defaultroom>

    action <north> {
        do <travel($thisobject$; north)>
    }
    ...
end define

C) Write a travel procedure something like this:

define procedure <travel>
	
	set string <p1; $parameter(1)$>
	set string <p2; $parameter(2)$>
	set numeric <nFoundExitObject; 0>
	
	set string <exit; #p1#_#p2#>
	if real <#exit#> then {
		if here <#exit#> then {
			if not property <#exit#; hidden> then {			
				doaction <#exit#; BeforeUse>
				inc <nFoundExitObject>
			}
		}
	}
	
	if (%nFoundExitObject% = 0) then {
		if property <#p1#; #p2#> then {
			goto <$objectproperty(#p1#; #p2#)$>
		}
		else {
			msg <You cannot go that way.>
		}
	}	

end define

Think you might have a slight problem with that code overcat (nFoundExitObject) - since the IF statement will never be true if it's an exit object..

I think the exits should have "define exit <>" instead of object personally.

.. But yes, in order of priority:

COMMAND (quest commands have their own priority structure)
Object
Action (these would include "north {..script..}" )
Property (these would include "north <room>" - not "north msg <value>" )

I still see a problem that exit objects are not handled in a "default" way (again - I haven't read the docs, sorry) yet..
IE, no pre-defined actions/properties/whatnot.
.. Then again maybe it's not needed? (since you'd be highly customizing the movement structure to take advantage of these objects in the first place?)

since the IF statement will never be true if it's an exit object..

Which IF statement?

I think the exits should have "define exit <>" instead of object personally.

I agree. One could still implement exits via 'define object', if one so desired.

COMMAND (quest commands have their own priority structure)
Object
Action (these would include "north {..script..}" )
Property (these would include "north <room>" - not "north msg <value>" )

I hadn't taken into account commands within a room (as far as priority). Will have to play with that to see what else I can do.

I still see a problem that exit objects are not handled in a "default" way (again - I haven't read the docs, sorry) yet..
IE, no pre-defined actions/properties/whatnot.
.. Then again maybe it's not needed? (since you'd be highly customizing the movement structure to take advantage of these objects in the first place?)

There is a 'locked' property, and a corresponding keyword. My opinion is that, the more ways there are to do something, the better. Redundancy can be a good thing.

if there's a "locked" - I'm guessing "unlocked" is basically a "not locked" alternative?
Because there used to be "alive" and "dead" - I wonder what happened to those?

The last if statement (if (nobjectexitsfound) ) - I tried to point it out with the name of the variable being compared.

As said, I'm a bit flippy-floppy over a standard/default exit-object handling method.
I'm not sure if there should or shouldn't since those using it would be customizing it etc.

if there's a "locked" - I'm guessing "unlocked" is basically a "not locked" alternative?

I think so.

The last if statement (if (nobjectexitsfound) ) - I tried to point it out with the name of the variable being compared.

Well, from my last testing in 4.1, the above worked regardless - I was implementing exit objects with 'define object'.

Ah sorry - just re-read the code and saw you were using it to check for objects and then properties.