I think SYS.Database (in %SYS), rather than Config.Databases, can accomplish what you want. Particularly, you can open an object representing a database, call its Delete() method, and then call %Save() on it. That seems to have the same effect you're looking for.

Here's a sample class (Demo.Recreate):

Include %occInclude

Class Demo.Recreate
{

ClassMethod Run(pDBDirectory As %String)
{
    new $Namespace
    zn "%SYS"
    try {    
        //Get the database
        set tDB = ##class(SYS.Database).%OpenId(pDBDirectory)
        If '$IsObject(tDB) {
            $$$ThrowStatus($$$ERROR($$$GeneralError,"Database "_pDBDirectory_" not found."))
        }
        
        write !,"Properties of database:",!
        zw tDB
        
        write !
        
        //For demonstration purposes: show contents of a global in that DB
        for i=1:1:10 {
            set ^["^^"_pDBDirectory]demo(i) = i
        }
        write "Contents of ^[""^^"_pDBDirectory_"""]demo: ",!
        zw ^["^^"_pDBDirectory]demo
        
        write !
        
        write "Deleting database..."
        $$$THROWONERROR(tSC,tDB.Delete())
        write " done.",!
        write "Recreating database..."
        $$$THROWONERROR(tSC,tDB.%Save())
        write " done.",!
        
        write !
        
        write !,"Properties of database:",!
        zw tDB
        
        write !
        
        //For demonstration purposes: show that contents of global in that DB are gone
        write "Contents of ^[""^^"_pDBDirectory_"""]demo: ",!
        zw ^["^^"_pDBDirectory]demo
        
        zw tDB
    } catch anyException {
        write anyException.DisplayString(),!
    }
}

}

Rather than projecting the property as a table, one option would be to write a custom class query that $orders over the index global, make the column name "KEYS", and make it an [SqlProc]. The SQL would then look like:

SELECT DISTINCT KEYS FROM MyClass_CustomQueryName()

It would be nice if there was a generic solution. My first thought was to add this query to an index class (i.e., one that extends %Library.CacheIndex) and generate <query>Fetch/Execute/Close methods for indices that on property(KEYS), but it seems that queries aren't supported as index members. The <indexName><query>Fetch/Execute/Close methods are generated in the persistent class, but there's no actual class query visible from SQL. Maybe %Library.FunctionalIndex would work if you don't mind reinventing the standard bitmap insert/update/delete, but I suspect that you'd end up losing FOR SOME %ELEMENT in this approach, and would need to replace it with %FIND.

I'll send you what I came up with while investigating - maybe it will provide food for thought.