This was originally posted over on a Casual Stroll to Mordor but as I’ve gotten a few comments on this I figured I’d post it as well. I’m glad to see we finally have a blue-name piping up on the forums to clarify what they’re planning to do with the Lua scripting. Here’s the link to Frelon’s post and you can read the rest of the thread – or his text is below:
We wanted to clarify a few things about the potential implementation of LUA scripting. As it stands right now, the LUA scripting ability is completely controlled by us and its use is limited.
The Framework API, which controls what can and cannot be done, is separated into two main functional areas. The Framework API provides the basic structure of the scripts (classes), UI creation (windows, buttons, images, etc.), and a controlled setting to receive input, events, and actions generated by the game. The Gameplay API provides access to internal gameplay systems. The first pass of the gameplay API includes access to your own character’s vitals, the ability to interface with quickslots, and the methods for interacting with items in your inventory.
So what does this all mean? Right now, given the limitations we have in place, the “plugins” players can create are restricted to the above Gameplay API areas. They can change some of your UI elements, add built in HUDS and allow for things like a travel panel or a single window inventory bag. Our intent is to not allow players to make “plugins” that will give them any kind of advantage over other players. The main idea here is that LUA allows the players the ability to customize their user interface the way they want to.
We are going to handle things very carefully as we move forward; to be very clear, LUA Scripting is still in the early stages of testing and we don’t yet have a date for when the system will go live.
The big things for me are that they’re being careful about what they allow and that you only have access to your own stuff not others, which I assume also means you don’t have access to information on mobs either. I think this is a great initial plan as it provides good utility and doesn’t open the flood gates to all sorts of other insanity (hopefully).
Doc Holiday's LOTRO Blog 
It’s hard to talk about this since beta players are under NDA, but I assume we can talk about what they talk about…
From what I’ve seen they’ve specifically limited things that give anyone any clear advantages they shouldn’t have. Their examples include a single inventory display, an improved morale display, etc.
I know a lot of people read LUA and think of crazy raid speccing on WoW. Really, at the end of the day, that’s for a specific group of players — those types of players already exist in LOTRO and run things like super hardcore raiding Kinships. If you’re not in one of those, I don’t even see how that sort of thing would affect you. The average WoW player doesn’t even use them.
More importantly, I think that has the negative side effect of completely glossing over all the awesome stuff LUA does do. I’m very excited for it in LOTRO and I think adding it to the game will really expand its appeal.
Yeah, I know very little about Lua but even with that little knowledge I’m quite excited about it. Not that the current UI is bad, but the ability to truly customize it will be great. Maybe I should poke around on some of the WoW interface sites a bit to see what’s possible.
I’m also encouraged by the restraint they are showing. There are plenty of ways to improve the LOTRO UI that don’t need information about anyone but you.
Tony mentions the “crazy raid speccing on WoW”, but in WoW these days those raiding addons don’t just affect raiders. It has shifted (more or less, depending on the server) the WoW community toward quantifying strangers as their gear and performance numbers. While that’s fine for the hardcore raider folks, it saps a lot of the fun and adventure from meeting new people and trying new things for casual players.
If LOTRO ever makes it possible to quantify the performance of others via Lua, I hope they limit this capability to the raid interface.