My expectation has been:

• Users write to the same POSIX-filesystem-appearing space as their Notebook Aspect home directory, their Notebook Aspect shared project space, and their Notebook Aspect scratch space. This could be provided via an actual POSIX filesystem, VOSpace, WebDAV, or something else.
• They can execute any code they like compatible with the CPU architecture available. Executables would either be shared with batch nodes via shared filesystem or, preferably, copied to batch nodes. Those executables should ideally be containerized.
• If there's a compelling reason (including better user experience), we could require that users submit to an instance of the workflow service used for DRP (although quite likely not the same instance) rather than submit directly to the underlying batch service. But we cannot insist on Gen3 pipelines and BPS unless we can provide a generic PipelineTask that invokes a file-based executable or script, and even then the boilerplate overhead may be prohibitive.

I am a tad concerned that this RFC discussion is now revolving around a poorly defined service to which we don't have a prototype, a conceptual design, or a rich set of requirements. There are a lot of ways to service requirements for user ad-hoc analytics; some of them can be serviced science-platform side, some can be serviced factory-batch side, and I would be fairly stunned if access to the latter was not gatekeeped in some way that if the as-yet non-existent user-factory-batch system required infrastructure accounts it would not be a problem.

I'd like to bring this RFC to a close by constraining it to the Science Platform. The only Science Platform requirement relating to user batch is that nublado provide shell access to the user batch system.

I think you are saying two things: "we believe that user-provided batch code execution is not part of the RSP, besides shell access" (and indeed it was anticipated that project DACs would use an underlying infrastructure component provided by the facility) and "we have not yet worked out the details of user-provided batch code execution, but have reason to believe that either this approach (accounts in the RSP service layer) will work or else underlying infrastructure accounts can be provided to such users for authentication, authorization, and resource management."  Is that correct?

I agree with Frossie. Let's handle user batch separately - but soon, so that USDF can make a plan.