I think that in the current state of things, MCServer is lacking a serious tutorial on how to write plugins, from scratch. So I decided that I'll try to write one up. And just so that it isn't in vain, I'll make a real plugin and this tutorial will also serve as its documentation. Expect this to be a long-going effort, a series of posts related to the life of a plugin 
Initial decision
So, I have decided to write a Protection plugin. I know some basic Lua and I have an extensive background in programming, so it shouldn't be too difficult. I know how MCServer works, and I can use google for when I need some details about Lua. Should the need arise, I can also make modifications to the Lua API exposed by MCServer, but that is not a precondition to writing plugins, it's enough to know that there is such a possibility, in the very last-resort scenario.
Workflow analysis
Now that I know that I want to do it, I need to really think about what it is that I want to do. What will my plugin exactly do, how will users interact with it, how will it work with other plugins, etc.
A Protection plugin should allow trusted users (let's call them VIPs) to define regions where only certain players may interact with the world. Interacting here means breaking blocks, placing blocks, opening chests and doors, and activating buttons. It should allow an indefinite number of such protected areas. For simplicity, the areas will be rectangular in shape (axis-aligned box). Areas may intersect each other, in such a case, users allowed in both areas will be able to interact with the intersection of the areas (think of "shared fences" here).
A feature for later inclusion will be the ability to allow interaction in an area based on user's group. For now, we will base our plugin solely on single users.
VIPs would use the plugin in the following way:
A1, Obtain a specified "wand" (configurable item, which will be used for marking the areas' corners)
A2, Click one corner of the wanted area, right-click the opposite corner of the area
A3, Use a command to make the area protected for a list of users
For administrative purposes, VIPs should be allowed to view a list of areas for a specified block, with the following workflow:
B1, Obtain a specified "wand"
B2, Click the block to be queried
B3, Use a command to list the protection areas to which the block belongs
To remove protection, VIPs will need a way to identify areas. A simple numerical ID will be used for that, this ID will be listed in the list (B3) and also will be shown when the area is created (A3). Removal workflow:
C1, Determine the area ID, using the Area list (B1-B3) or when the area is created (A3)
C2, Use a command to delete the area by ID
When multiple users are assigned to a single area, we need a way to add and remove users to the area's list:
D1, Determine the username
D2, Determine the area ID (B3 or A3)
D3, Use a command to add or remove the user to the area. If the area has no users, it will be deleted altogether (?).
It may be useful for when a user is deemed bad, to have a way of removing all protection areas for a specified user, with the following workflow:
E1, Determine the username
E2, Use a command to delete all areas with the specified username. If any area has no users, it will be deleted altogether (?).
For some special cases, it might be beneficial to allow specifying the area not by a wand, but by coords:
F1, Determine the coords for the area
F2, Use a command to make the area protected for a list of users
Now with this cleared up, we can finally come up with the commands needed for operating this plugin:
ProtWand - gives the VIP the "wand" item (A1)
ProtAdd - adds a new protected area, marked out previously by the wand. Parameters specify usernames to allow (A3)
ProtList - lists all protected areas for the previously marked block. (B3)
ProtDelID - deletes a protection area by its ID (C2)
ProtAddUser - adds a user to a protection area (D3), parameters are area ID and username
ProtRemUser - removes a user from the protected area (D3), parameters are area ID and username
ProtRemUserAll - removes a user from all protected areas (E2), parameter is the username
ProtAddCoords - adds a new protected area by coordinates. Parameters are 6 coords, then usernames to allow (F2)
(to be continued)
Initial decision
So, I have decided to write a Protection plugin. I know some basic Lua and I have an extensive background in programming, so it shouldn't be too difficult. I know how MCServer works, and I can use google for when I need some details about Lua. Should the need arise, I can also make modifications to the Lua API exposed by MCServer, but that is not a precondition to writing plugins, it's enough to know that there is such a possibility, in the very last-resort scenario.
Workflow analysis
Now that I know that I want to do it, I need to really think about what it is that I want to do. What will my plugin exactly do, how will users interact with it, how will it work with other plugins, etc.
A Protection plugin should allow trusted users (let's call them VIPs) to define regions where only certain players may interact with the world. Interacting here means breaking blocks, placing blocks, opening chests and doors, and activating buttons. It should allow an indefinite number of such protected areas. For simplicity, the areas will be rectangular in shape (axis-aligned box). Areas may intersect each other, in such a case, users allowed in both areas will be able to interact with the intersection of the areas (think of "shared fences" here).
A feature for later inclusion will be the ability to allow interaction in an area based on user's group. For now, we will base our plugin solely on single users.
VIPs would use the plugin in the following way:
A1, Obtain a specified "wand" (configurable item, which will be used for marking the areas' corners)
A2, Click one corner of the wanted area, right-click the opposite corner of the area
A3, Use a command to make the area protected for a list of users
For administrative purposes, VIPs should be allowed to view a list of areas for a specified block, with the following workflow:
B1, Obtain a specified "wand"
B2, Click the block to be queried
B3, Use a command to list the protection areas to which the block belongs
To remove protection, VIPs will need a way to identify areas. A simple numerical ID will be used for that, this ID will be listed in the list (B3) and also will be shown when the area is created (A3). Removal workflow:
C1, Determine the area ID, using the Area list (B1-B3) or when the area is created (A3)
C2, Use a command to delete the area by ID
When multiple users are assigned to a single area, we need a way to add and remove users to the area's list:
D1, Determine the username
D2, Determine the area ID (B3 or A3)
D3, Use a command to add or remove the user to the area. If the area has no users, it will be deleted altogether (?).
It may be useful for when a user is deemed bad, to have a way of removing all protection areas for a specified user, with the following workflow:
E1, Determine the username
E2, Use a command to delete all areas with the specified username. If any area has no users, it will be deleted altogether (?).
For some special cases, it might be beneficial to allow specifying the area not by a wand, but by coords:
F1, Determine the coords for the area
F2, Use a command to make the area protected for a list of users
Now with this cleared up, we can finally come up with the commands needed for operating this plugin:
ProtWand - gives the VIP the "wand" item (A1)
ProtAdd - adds a new protected area, marked out previously by the wand. Parameters specify usernames to allow (A3)
ProtList - lists all protected areas for the previously marked block. (B3)
ProtDelID - deletes a protection area by its ID (C2)
ProtAddUser - adds a user to a protection area (D3), parameters are area ID and username
ProtRemUser - removes a user from the protected area (D3), parameters are area ID and username
ProtRemUserAll - removes a user from all protected areas (E2), parameter is the username
ProtAddCoords - adds a new protected area by coordinates. Parameters are 6 coords, then usernames to allow (F2)
(to be continued)