subj with
- one shared GC.
- any D-types can be called from script without interop. but it should be allowed to call from script engine by module or by explicit list of types (we can add types dynamically at runtime). exception: script can use (d/w)string and fundamental types (ulong, float..). i.e D-types should/can be proxied or white-listed not only for types but for some connection-string. for example we can allow scripts to use TCP sockets but we allow connection to some hosts per host basis. some D-type ScriptTCPSocket( string endpoint ) that has white-listed host list or some callback to D-code that decide what allow and what deny.
- script can use functions and methods with function-pointer. so, script cannot use inlined D-functions or uninstantiated D-templates.
- script can use same class-object and structs dispositions and function calling convention - VTBL, UFCS, operators..
- Dlang compiler itself as runtime script engine is to heavy, so script engine use light version with no parser, with no pointer types and pointer math.
- when u have AST or expression trees from which script engine can generate code (LLVM) u can use any DSL or script types - Lua, JavaScript, any what u want.
- with possibility change code on the fly. (how to store current living objects and how to restore their VTBL?)
- I thought about WASM engine, but WASM-restrictions disallow shared GC and types and adds interop.. so, probably not.

subj looks like Terra-lang for Lua or QScript/QML for Qt, Roslyn/Compiler-as-Service for .NET

why it needed built-in script engine as language feature?
again, with such script engine dont need any interop - strings and objects in same GC and same type and same VTBL, all same, just dynamic code generation that already exists in LDC (OFFTOPIC: so LDC can link JIT-code to AOT-code - if JIT calls toLower(string) AOT knows where is it(address) and etc - some kind of compiler generated MAP of functions).
question still without answer.
u can:
- using scripts as application extension is obvious. generate code for user diagrams. from AST we can generate text representation of logic for another lang: we have script, it works fine, we can generate Dlang code and compile it with AOT to new version of application for more benefits without rewriting it from Lua to Dlang/R.
- (in case we have GUI-library with some DSL) designers can edit WYSIWYG-forms like QML (how will work intellisense for them if they want add some data-validator code? need to think). Capability of QML is awesome.
- in case u have connection string to DB AOT can generate appropriate types for access/modify DB-data with probably default forms for editing/viewing with possibility to change such GUI. (why not to generate that with some tools and after this step compile whole application? need to think. probably wrong example). the same can be applied to REST/SOAP services.
- what else?

IMO it will be killer-feature (and I cannot to offer the killer use case :)