1. No
2. Not that I'm aware of. If bugs are discovered, they will be fixed.
3. No limit other than what is sensible given the available CPU power. However you say "simunatenously", so to keep things clear I must say that there is (currenty) no proper support for concurrency. If you want to have different scripts run "simunatenously", you would do just like in standard BlitzMax/Blitz3D (such as having an "Update" function scripts, called each frame). Also in my opinion it is best here to take advantage of the OOP support: rather than creating one script per "entity", write a new type per kind of entity. It's more manageable, and even more resource friendly. But it's just an advice, you may integrate scripts as you see fit.
4. Absolutely. Giving the end user the ability to MOD your game is one the biggest intended use for BriskVM. No licensing problem here. Only the developer(s) integrating BriskVM need a license, the runtime is then free to use and redistribute. As stated in the EULA, you can actually redistribute pretty much everything except the "bvmtools" shared library (which is only needed for the developer integrating BriskVM, and unneeded for cscript compilation nor execution).
5. Exact. One point though: as the license states, established game portals are also interpreted as commercial, so if you get a deal with such a portal you should have a commercial license. If on the other hand you distribute your games via your site you certainly qualify as "indie" :)
In any case, there is an upgrade from "indie" to "commercial", so you don't have to worry about wether you'll go "commercial" or not in the future. You can switch when you want and only pay the difference.
2. Not that I'm aware of. If bugs are discovered, they will be fixed.
3. No limit other than what is sensible given the available CPU power. However you say "simunatenously", so to keep things clear I must say that there is (currenty) no proper support for concurrency. If you want to have different scripts run "simunatenously", you would do just like in standard BlitzMax/Blitz3D (such as having an "Update" function scripts, called each frame). Also in my opinion it is best here to take advantage of the OOP support: rather than creating one script per "entity", write a new type per kind of entity. It's more manageable, and even more resource friendly. But it's just an advice, you may integrate scripts as you see fit.
4. Absolutely. Giving the end user the ability to MOD your game is one the biggest intended use for BriskVM. No licensing problem here. Only the developer(s) integrating BriskVM need a license, the runtime is then free to use and redistribute. As stated in the EULA, you can actually redistribute pretty much everything except the "bvmtools" shared library (which is only needed for the developer integrating BriskVM, and unneeded for cscript compilation nor execution).
5. Exact. One point though: as the license states, established game portals are also interpreted as commercial, so if you get a deal with such a portal you should have a commercial license. If on the other hand you distribute your games via your site you certainly qualify as "indie" :)
In any case, there is an upgrade from "indie" to "commercial", so you don't have to worry about wether you'll go "commercial" or not in the future. You can switch when you want and only pay the difference.